# DBLab Engine: PostgreSQL branching and thin cloning for CI > DBLab Engine is an Apache-2.0 Go service that gives PostgreSQL databases fast copy-on-write clones. It fits teams that need production-sized databases in CI, and it does not fit teams without ZFS or LVM to run it on. **postgres-ai/database-lab-engine** — DBLab enables 🖖 database branching and ⚡️ thin cloning for any Postgres database and empowers DB testing in CI/CD. This optimizes database-related costs while improving time-to-market and software quality. Follow to stay updated. - Repository: https://github.com/postgres-ai/database-lab-engine - Website: https://postgres.ai/products/how-it-works - Stars: 2,728 · Forks: 86 - Language: Go - License: Apache-2.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/postgres-ai-database-lab-engine ## The problem DBLab Engine solves: production-sized databases in CI Most teams cannot run their real database in a test pipeline. A 1 TiB PostgreSQL instance does not fit in a CI runner, and restoring a logical dump takes hours. So teams test against a small fixture, and migrations that pass in CI fail on the real dataset. DBLab Engine targets exactly that gap. The README states its purpose plainly: build dev, QA and staging environments using full-scale, production-like databases, test database changes in CI/CD pipelines, and provide temporary full-size clones for SQL query analysis. The audience is database and platform engineers who own a PostgreSQL instance that is too large to copy, and who want dozens of independent clones on one machine without buying more hardware. The README gives one number to anchor expectations: cloning a 1 TiB PostgreSQL database takes about 10 seconds. That figure is the project's own claim, not something verified here, and it depends on the underlying snapshot technology. ## How thin cloning works: ZFS and LVM snapshots behind a Go engine The mechanism is copy-on-write. The README says DBLab employs two technologies for thin cloning, ZFS (the default) and LVM, and that using ZFS it routinely takes new snapshots of the data directory. A clone is therefore not a copy of the data. It is a new writable filesystem view over an existing snapshot, and only the blocks a clone changes consume new space. That is why clone time is closer to filesystem metadata work than to data transfer, and why many clones can share one machine. The engine itself is written in Go and ships as a server component plus a CLI. The repository layout shows this split: an `engine/` directory for the Go service, a `ui/` directory, and `docs/`. The README points to postgres.ai/docs for the full documentation, and it also notes a constraint that shapes deployment: for managed services such as AWS RDS or Heroku, direct physical connection and PGDATA access are not possible, so DBLab must run on a separate VM in the same region and auto-refresh its data. That is a real architectural boundary. Thin cloning needs access to the data directory, and a managed service does not give it to you. ## Installing DBLab Engine and taking a first clone The README does not inline installation commands. It points to two paths. For the paid Standard Edition, you provision through the Postgres.ai Console and follow the how-to guide at postgres.ai/docs/how-to-guides/administration/install-dle-from-postgres-ai. For the free Community Edition, the README links a tutorial at postgres.ai/docs/tutorials/database-lab-tutorial. That tutorial is where the actual commands live; the README does not reproduce them, so follow it rather than guessing at flags or package names. What the README does give you is a way to see the result without installing anything. It lists a demo at demo.dblab.dev with the token `demo-token`, which the README says to use to access it. The README also links the Postgres.ai Console, where you set up your first organization and provision a DBLab Standard Edition to any cloud or on-premises environment. The repository layout confirms what you will be installing: `engine/` is the Go service, `ui/` is the web interface, and `docs/` holds the documentation sources. Expect the server component to need a host with ZFS or LVM already configured, because that is the snapshot layer the whole design rests on. ## Where DBLab Engine is the wrong tool The dependency on ZFS or LVM is the first limit. If your CI runners are ephemeral containers on a managed Kubernetes cluster, you do not have a ZFS pool to snapshot, and DBLab has nothing to work with. The second limit is the managed-service case. The README is explicit that AWS RDS, GCP Cloud SQL, Supabase and Timescale do not permit direct physical connection or PGDATA access, so DBLab runs on a separate VM in the same region and refreshes its data on a schedule. That means your clones are as fresh as the last refresh, not as fresh as production. The third limit is scope: DBLab clones PostgreSQL. It is not a migration tool, not a schema-diff tool, and not a replacement for `pg_dump` when you need a portable artifact. If your test database is 200 MB and rebuilds in seconds from a fixture, the snapshot machinery adds an operational component without buying you anything. The README does not document rollback behavior for a clone that has diverged, and it does not describe how conflicts between clones are handled, so treat that as something to test on your own before relying on it. ## DBLab Engine compared with template databases and pg_dump The obvious alternative is PostgreSQL's own `CREATE DATABASE ... TEMPLATE`, which copies a database inside the same server. It is simple and needs no extra software, but it is a physical copy: a 1 TiB template means 1 TiB of new files, and the copy takes as long as the storage takes to write. A second alternative is restoring a dump per test run, which is portable and works anywhere PostgreSQL runs, but the restore time scales with data volume and it produces a full copy each time. DBLab's difference is that it operates below PostgreSQL, at the filesystem snapshot layer, so the copy is metadata plus copy-on-write blocks. That is the trade: you get speed and density, and you pay for it with a host that must run ZFS or LVM and a server component that must keep snapshots refreshed. The README also mentions Joe, a SQL optimization chatbot, as a consumer of temporary full-size clones, which shows the intended pattern: throwaway clones created for one analysis and discarded. ## Maintenance, releases and the Apache-2.0 licence The repository is not archived, and the last push was on 2026-09-17. Releases are frequent: v4.2.0 on 2026-09-11, v4.1.4 on 2026-09-01, and v4.1.3 on 2026-05-08. The gap between v4.1.3 and v4.1.4 is about four months, so patch cadence is not uniform, but the project is being pushed to. Upgrade cost depends on which edition you run. The Community Edition is self-hosted, so an upgrade means replacing the server binary and the CLI and re-checking your snapshot configuration. The Standard Edition is provisioned through the Postgres.ai Console, where the README says pricing starts at $62/month. The licence is Apache-2.0, which permits commercial use and modification with the usual notice and patent terms. Nothing here is legal advice; read LICENSE in the repository before you redistribute a modified build. One practical point: because clones are snapshots, an engine upgrade that changes snapshot handling is worth testing against a non-production pool first. ## Conclusion Adopt DBLab Engine if your CI needs full-size, production-like PostgreSQL databases and you can run ZFS or LVM on the host. Do not adopt it if you need clones without filesystem snapshots, or if you cannot run a separate server component. Before committing, verify two things: that your host already has ZFS or LVM configured, and that the Community Edition tutorial at postgres.ai/docs/tutorials/database-lab-tutorial matches your PostgreSQL version. ## FAQ ### What is DBLab Engine used for? It provides thin cloning and branching for PostgreSQL so teams can build dev, QA and staging environments from full-size, production-like databases, and test database changes in CI/CD pipelines. The README also lists SQL query analysis and validating LLM-generated SQL as uses. ### Does DBLab Engine work with AWS RDS or other managed PostgreSQL services? Yes, but with a caveat the README states directly: managed services like AWS RDS or Heroku do not allow direct physical connection or PGDATA access, so DBLab must run on a separate VM in the same region and auto-refresh its data. ### What does DBLab Engine require on the host? Thin cloning is based on copy-on-write, and the README says DBLab employs ZFS as the default technology and LVM as the alternative. Without one of those snapshot layers there is nothing for the engine to clone from. ### Is DBLab Engine free? There is a free Community Edition, installed by following the tutorial linked from the README, and a Standard Edition provisioned through the Postgres.ai Console with pricing that the README says starts at $62/month. The source is licensed under Apache-2.0. ## Sources - [License: Apache-2.0](https://github.com/postgres-ai/database-lab-engine/blob/master/LICENSE) - [postgres-ai/database-lab-engine on GitHub](https://github.com/postgres-ai/database-lab-engine) - [Project website](https://postgres.ai/products/how-it-works) - [README](https://github.com/postgres-ai/database-lab-engine/blob/master/README.md) - [Releases](https://github.com/postgres-ai/database-lab-engine/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/postgres-ai-database-lab-engine