DBLab Engine version 3.4, an open-source tool for PostgreSQL thin cloning and database branching, has been released with numerous improvements.
Rapid, cost-effective cloning and branching are extremely valuable when you need to enhance the development process. DBLab Engine can handle numerous independent clones of your database on a single machine, so each engineer or automated process can work with their own database created within seconds without additional expenses. This enables testing of any changes and optimization concepts, whether manually or in CI/CD pipelines, as well as validating all the concepts suggested by ChatGPT or another LLM. This effectively addresses the issue of LLM hallucinations.
New name: DBLab Engine
The new name for the Database Lab Engine is "DBLab Engine". Updates are currently underway across our materials to reflect this change. To align with this change, we have introduced specific domains for the product:
dblab.sh. For ease of access, we have established the following short URLs:
- https://cli.dblab.dev/ and https://dblab.sh – CLI setup script (works on macOS/Linux/Windows:
curl -sSL dblab.sh | bash)
- https://demo.dblab.dev/ – DBLab 3.4 demo (token:
- https://branching.dblab.dev/ – DBLab 4.0-alpha demo, implementing full-fledged DB branching and snapshots on demand (token:
- https://aws.dblab.dev/ – DBLab SE page in AWS Marketplace
- https://docs.dblab.dev/ – the docs
- https://api.dblab.dev/ – interactive API reference (powered by readme.io)
By the numbers
- DBLab GitHub repository has crossed the 1700+ stars mark
- X/Twitter account @Database_Lab has more than 1300 followers
- Our LinkedIn page has amassed 1500+ followers
Thank you for the support!
New DBLab SE installer
This setup is entirely automated and can be used anywhere:
- For those who have existing machines, we support the "BYOM" (Bring Your Own Machine) method
- If you're utilizing AWS, GCP, DigitalOcean, or Hetzner Cloud, the installer handles resource provisioning—including VMs, disks, and more—automatically.
Check out step-by-step tutorial.
New configuration options
To improve control over how clones are created, it is now possible to configure network interfaces that will be used for clone containers, using new option
cloneAccessAddresses. It is set to
127.0.0.1 by default, meaning that only local TCP connections will be allowed. It is possible to specify multiple addresses, and IPv6 is also supported: see the docs.
ignoreErrors and skipPolicies for logical data provisioning
Some DBLab Engine users experienced issues with logical data provisioning (automated full refreshes that use
pg_restore), so the following two convenient flags were added to help mitigate those issues:
logicalRestoreto allow not to interrupt the process of dump/restore in case of errors,
logicalRestoreto allow to skip policies (
CREATE POLICY) during restore process.
Postgres restarts in clone containers
Postgres clone containers under DBLab Engine's management were always supposed to support Postgres restarts - although, due to a bug, it didn't really work in versions 3.0—3.2. With a proper fix, it works again – just make sure you're using tags with the
-0.3.0 suffix or later, such as
With restart support, it is possible, for example, to run
pg_upgrade -k inside a particular clone container (of course, with previous installation of newer binaries) – and start testing a newer Postgres major version right away, in an isolated environment. And, most importantly, you don't need to spend extra time or money – this is exactly why we created and develop DBLab Engine. Any testing has to be fast, cheap, and scalable, even for mutli-terabyte databases.
The "Configuraion" tab received numerious improvements (though, config editing is still only supported for the logical mode), as well as "Logs" which now has filter buttons:
Postgres images for DBLab: pgvector and upgrades
And, as usual, upgraded all extensions to most up-to-date. See the full list of extensions in the docs.
For the DBLab SE, we also prepared special sets of our Postgres container images, with Postgres versions 10-15, and extensions that are needed to run DBLab Engine for the following source databases:
- GCP Cloud SQL for PostgreSQL
- Amazon RDS for PostgreSQL
- Amazon Aurora PostgreSQL
There is a huge number of improvements in DBLab Engine 3.4.0 – this release has the largest number of changes ever. Please read the full list of changes in the CHANGELOG. If you need to upgrade an existing DBLab Engine to 3.4.0, do not forget to follow the Migration Notes.
Where to start / get help
Provide feedback, contribute
We greatly value your feedback. Connect with us via:
Additional resources where you can get insights about DBLab and Postgres:
Interested in giving back to the project? Here's how you can make an impact:
- Give a star to our GitHub repository
- Help us reach more enthusiasts. Share about Database Lab on Twitter (don't forget to tag @Database_Lab) or any other platform you fancy
- Multilingual? Consider translating our README.md to share the knowledge in your language
- Are you a developer? Dive in and enhance the Database Lab Engine (DLE) experience; check out our CONTRIBUTING guidelines and explore the "good first issues" list on GitLab
Share this blog post:
Database Lab by Postgres.ai
An open-source experimentation platform for PostgreSQL databases. Instantly create full-size clones of your production database and use them to test your database migrations, optimize SQL, or deploy full-size staging apps.