Skip to main content

DBLab 3.4: new name, SE installer, and lots of improvements

· 6 min read

DBLab Engine 3.4: new name, SE installer, and lots of improvements

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: and For ease of access, we have established the following short URLs:

By the numbers

Thank you for the support!

New DBLab SE installer

We've expanded the installation options for DBLab SE. Besides its presence in the AWS Marketplace, you can now seamlessly install DBLab SE directly from the Console.

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 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_dump/pg_restore), so the following two convenient flags were added to help mitigate those issues:

  • ignoreErrors in subsections logicalDump and logicalRestore to allow not to interrupt the process of dump/restore in case of errors,
  • skipPolicies in subsection logicalRestore to 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 postgresai/extended-postgres:15-0.3.0.

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.

UI improvements

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:

API docs

As already mentioned, we now have a short URL for the API docs: It is backed by excellent service ReadMe, and is based on the OpenAPI spec that you can find in Git. is interactive, you can use the token demo-token to test API calls for the demo instance (

Postgres images for DBLab: pgvector and upgrades

Following the obvious trends, we added pgvector to the Postgres images for DBLab Engine.

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
  • Supabase
  • Timescale
  • Heroku
  • PostGIS

Other changes

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:

Share this blog post:

Nikolay Samokhvalov
Nikolay Samokhvalov

CEO & Founder of

Working on tools to balance Dev with Ops in DevOps

Database Lab
Database Lab by

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.