DBLab data sources
Guides​
Logical​
- Dump
- RDS
- RDS/Aurora refresh — refreshes from a temporary RDS clone instead of production
- Full refresh
Shared​
Physical​
Overview​
To start using cloning, you first need to transfer the data to the DBLab Engine machine. Data retrieval can also be considered "thick" cloning. Once it is done, users can use "thin" cloning to get independent, full-size clones of the database in seconds, for testing and development. Retrieval (thick cloning) is normally a slow operation (1 TiB/h is a good speed). Optionally, you can configure the DBLab Engine data directory to stay in sync with the source as it is continuously updated.
Read how you can protect personal data: Data masking.
Data retrieval types​
Logical​
Use dump/restore processes to obtain a logical copy of the initial database (as a set of SQL commands), then load it into the target DBLab Engine data directory. This is the only option for managed cloud Postgres services such as Amazon RDS.
Physically, the copy of the database created with this method differs from the original (data blocks are stored differently). However, the row counts are the same, as are the internal database statistics, so you can perform various kinds of development and testing, including running the EXPLAIN command to optimize SQL queries.
Physical​
Physically copy the data directory from the source (or from the archive if a physical backup tool such as WAL-G, pgBackRest or Barman is used).
This approach gives you a copy of the original database that is physically identical, including the existing bloat and data block layout. It is not available for managed cloud Postgres services such as Amazon RDS.