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: dblab.dev and dblab.sh. 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 Postgres.ai 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​

cloneAccessAddresses​

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_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: API.dblab.dev. It is backed by excellent service ReadMe, and is based on the OpenAPI spec that you can find in Git.

API.dblab.dev is interactive, you can use the token demo-token to test API calls for the demo instance (demo.dblab.dev):

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 Postgres.ai

Working on tools to balance Dev with Ops in DevOps

Database Lab
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.