The Database as Code Landscape

This is a series of articles about database version control and database-as-code (GitOps)

1. What is Database Version Control?
2. Database Version Control, State-based or Migration-based?
3. Database as Code - the Good, the Bad and the Ugly
4. The Database as Code Landscape (this one)
5. Database Version Control Best Practice

Originally published in June 2022. In October 2026 we added a 2026 landscape table and a short 2026 check at the end of each section. The 2022 text is left as written, so you can see which calls held up.

The idea of codifying database schema changes (aka schema migration) is not new. Many engineering teams have employed Liquibase / Flyway to adopt this practice. At the same time, we are observing an accelerated trend of embracing Database as Code (DaC) across the industry. Several innovative products have also emerged to challenge the incumbents.

In this blog, we will review the state-of-the-art in the Database as Code landscape and share our own insight into the current and future trends in this space.

The Overview#

Where everyone stands as of October 2026. GitHub stars are a popularity signal, not usage.

Put simply: the migration CLIs are roughly where they were. The biggest changes happened inside the databases.

The Gatekeepers#

Liquibase#

Started in 2006, Liquibase is arguably the most well-known product in this segment. When someone asks for database schema change advice on a forum, oftentimes, you will see a reply mentioning Liquibase.

Liquibase is both an open source project as well as a company providing its commercial offering. The company used to be called Datical, and was renamed Liquibase to consolidate the branding (wise move). Liquibase main product is a Java-based CLI. Via the CLI, developer teams can integrate the database schema migration into their CI/CD workflow. For the Java application, Liquibase can also be used as a library. Applications usually embed Liquibase library to apply any applicable schema migration on startup.

In Liquibase, a schema migration unit is encapsulated in a Change Set. Probably due to its age and root in Java, the most commonly used form is XML (YAML and JSON support have been added later):

Plain SQL is also supported with proper annotation:

Liquibase is migration-based. It records the incremental change instead of the desired end state of the target database schema.

Recently, Liquibase introduced HUB, it's an information portal for paid customers to view, organize and monitor database change activity in real-time.

2026 check: Hub is gone. Liquibase sunset it in 2023 and moved the reporting into its paid product, which is now called Liquibase Secure. The bigger change came with 5.0 in September 2025. Liquibase Community moved from Apache 2.0 to the Functional Source License, which converts to Apache 2.0 after two years, and contributors now sign a CLA. 5.0 also requires Java 17. We called Liquibase the enterprise-leaning one in 2022. The license change is the clearest proof.

Liquibase Secure 6.0 followed on September 30, 2026. It is no longer a CLI with a license key: it ships a self-hosted server with RBAC, SSO, an audit log, and a central policy catalog, and it is marketed as "a unified platform for database change governance." Liquibase Community stays at 5.0.4 under FSL. The enterprise-leaning one in 2022 is now openly a governance platform.

Flyway#

Flyway resembles Liquibase in many ways. It's an open source project with a long history and a large customer base. Its core product includes the CLI and a Java library. Flyway also recently announced a web portal named Hub.

The commercial entity behind Flyway is Redgate through an acquisition. The branding may cause some confusion, while it also sets a boundary between the open source and commercial offering. Flyway carries a more casual branding tone:

Flyway website is not as shining as those new DevTools companies using sophisticated gradients. You can even spot some basic UI spacing issues. Yet Flyway shows a classic example that content matters more than cosmetic beauty and its documentation stands out because of the clarity.

Liquibase and Flyway are neck and neck. The major difference lies in their respective positioning. Liquibase caters to enterprise customers, while Flyway feels more accessible to the developers.

2026 check: Flyway is still Apache 2.0 at the core and Redgate still ships it roughly monthly (13.9 landed on October 1, 2026). Since May 2025, new buyers can no longer purchase Flyway Teams; the paid path is Flyway Enterprise. Redgate has also been adding AI agent hooks: a flyway mcp command (Enterprise, preview) lets agents diff schemas and generate migration scripts. On GitHub, Flyway now has about twice Liquibase's stars.

Sqitch#

Sqitch is also an open source project been on the market for a while. Sqitch is pure CLI-based and has no UI. Unlike Java-based Liquibase/Flyway, Sqitch is developed in Perl.

Choosing Perl is not the only interesting aspect. Sqitch has its own design philosophy about how to manage database schema changes. Both Liquibase and Flyway use the file naming convention to control the schema migration behavior (convention over configuration):

While Sqitch takes an explicit approach. In the below example, you need to name the schema migration as appschema:

If you later want to apply another migration depending on appschema, you need to supply with --requires:

Sqitch also provides the unique tag and bundle command for the schema change deployment, which grants teams more power to wire the schema deployment into the application development lifecycle.

2026 check: Sqitch is the same tool it was in 2022, which is a compliment. Still Perl, still CLI only, still explicit about dependencies. v1.6.1 shipped in January 2026. It never tried to grow a UI or a company around it.

The Starlets#

Atlas#

Atlas is a new database schema migration tool that debuted recently. It takes traits from existing tools:

• It resembles Liquibase / Flyway / Sqitch in that it's mainly CLI focused, though it also has a lightweight UI to visualize the schema.
• It resembles Prisma in that it designs its own Domain Specific Language (DSL) to define the database schema. Originally, it chooses the same state-based approach as Prisma, but looks like it also added the migration-based approach.

• It's also heavily influenced by HashiCorp Terraform, using Go and inventing its own DSL. They even debuted as Terraform for Database Migrations on Hacker News:

Altas current focus is on CLI. While stacking it against existing CLI tools like Liquibase / Flyway, it has the advantage of employing a modern programming language (Go instead of Java), and learnings from tools like Terraform and Prisma.

2026 check: The Starlet label held up. Atlas reached v1.3 in August 2026 and offers both the state-based and the versioned workflow, as we guessed it would. It also grew a commercial layer: the Community Edition stays Apache 2.0, while the standard build carries commercial terms and some commands (for example migrate lint) need Atlas Pro.

The ORMs#

Database schema migration is an integral part of the application development, thus it's no surprise popular application frameworks and ORMs provide the built-in schema migration capabilities:

• Ruby on Rails Active Record Migrations (Ruby)
• Django Migrations (Python)
• MyBatis Migrations (Java)
• GORM Migrations (Go)

Though database schema migration falls into the backend category, the most recent innovation comes from Prisma, an ORM with a frontend root.

Prisma#

Node.js unlocks the pandora box for frontend engineers to build full-stack applications. We call it pandora box because it brings both prosperity and chaos. Full-stack applications consist of 3 pieces:

1. The code (stateless part).
2. The data (stateful part).
3. And how the code interacts with the data.

To a typical frontend engineer wanting to build a sustainable full-stack application, TypeScript / Express.js is solving the code problem. NoSQL databases like MongoDB are solving the data problem. Prisma is targeting the last problem of wiring code with data.

For frontend engineers, usability and accessibility are especially important. They are used to perfect pixels and HCI, and are not versed in composing SQL. To lower the barrier of managing database schemas, Prisma specifically designs a DSL:

The DSL takes the state-based approach (declarative), in that the DSL describes the desired end state of the targeting database schema instead of the incremental changes. This is different from Liquibase / Flyway / Sqitch.

Prisma also invests heavily in the integration and development workflow.

Unlike its backend ORM peers, Prisma takes a refreshing approach and offers a more holistic view of managing database data and schema throughout the application development lifecycle.

By looking at their product line, you can easily tell their ambitions are definitely not limited to being an ORM and schema migration tool.

2026 check: "Their ambitions are definitely not limited to being an ORM" turned out to be an understatement. Prisma launched Prisma Postgres, a managed database, and made it generally available in February 2025. Prisma ORM 7 then dropped the Rust query engine. The ORM is now the on-ramp to a database business.

The Database#

All tools described above work with many different database systems. While the application of Database as Code is database agnostic, there emerge new database systems promoting developer experience as a key differentiator. This developer-centric perspective as well as features like branching / cloning aligns with the mindset behind Database as Code.

PlanetScale#

PlanetScale used to be a Vitess hosted service. They pivoted last year to focus on the developer workflow. Though you may still come across some Vitess footprint on their website, most new materials are talking about database development workflow features such as branching, online schema change, and the recently introduced rewind:

When we covered Prisma above, we mentioned there are 3 pillars constituting a full-stack application:

1. The code (stateless part).
2. The data (stateful part).
3. And how the code interacts with the data.

For the data part, MongoDB is a popular choice, people choose it because of its usability rather than ubiquity. For hosting mission-critical application data such as user info, customer order, and billing, you still want a SQL-based relational database. PlanetScale is based on MySQL, enhanced with Vitess scalability, and crafted for usability by the amazing PlanetScale product team. These properties make PlanetScale an attractive choice. It seems to combine the best of both worlds, retaining all the SQL database benefits while not sacrificing developer experience.

Neon#

Neon is another open source database just announced.

At a high level, it shares a lot of similarities with PlanetScale, serverless, developer productivity, fully managed.

The major difference lies in the technology stack:

• Neon is on the PostgreSQL camp while PlanetScale is MySQL-based.
• PlanetScale leverages Vitess to offer its advanced database features, while Vitess itself is a middleware on top of the MySQL server node. Neon takes a more drastic approach to build a dedicated storage layer to offer those desired features.

Neon could have higher potential because it has better control over the entire stack. It would be very interesting to see how Neon progresses compared to PlanetScale. The love-hate relationship between MySQL and PostgreSQL is never-ending, from vanilla MySQL vs PostgreSQL, distributed database TiDB vs CockroachDB, cloud database AWS Aurora vs GCP AlloyDB, and now to the developer-centric database PlanetScale vs Neon.

2026 check: This is the section that aged the most, so it gets the longest update.

PlanetScale changed in two ways. It retired the free Hobby plan in April 2024, which upset a lot of side projects. Then it went after Postgres: PlanetScale for Postgres became generally available in September 2025. The MySQL vs. PostgreSQL fight we described ended in an odd place. The MySQL-based developer database added Postgres.

Neon went somewhere nobody predicted in 2022. Databricks agreed to acquire it in May 2025, in a deal reported at around $1B, and turned its technology into Lakebase. The reason Databricks gave is telling: over 80% of the databases provisioned on Neon were created by AI agents, not people. We wrote that Neon "could have higher potential because it has better control over the entire stack." On technology, that was right. Copy-on-write storage made a branch cheap enough for an agent to create one per task. On the buyer, we were wrong. It was a data platform, not a developer platform.

For Database as Code, branching solves half the problem. A branch gives every developer (and every agent) a private copy of the schema and data to break. It does not get the change back to production:

• On PlanetScale's MySQL side, a branch's schema change goes back to production through a deploy request, a review step built into the database.
• On Neon, a branch never merges. "Reset from parent" overwrites the branch with the parent's latest state, and the schema change still reaches the main branch as a migration.

So the migration file, the review, and the rollout are still needed. Branching made it cheaper to try a change. It did not make it safer to ship one.

The Misfits#

Dolt#

Dolt is unique on its own. The website describes it as a database system with Git-like version control.

Dolt is drastically different from other database systems because it builds an engine with built-in Git semantics. This is a double-edged sword, on one hand, it brings those desired Git properties, on the other hand, it imposes challenges of optimizing the typical OLTP workload.

Dolt takes a much bolder move to adopt Database as Code since it blurs the lines between database and code. It currently positions itself as bringing the Git semantics into the database. Would the other way around work as well or even better, bringing the database semantics into Git? After all, many applications have already used Git as the only data store.

2026 check: Dolt kept going and went Postgres too. Dolt is at v2.4, and Doltgres, the Postgres-compatible version, reached 1.0 on August 6, 2026. DoltHub reports 99% Postgres compatibility and queries about 2.7x slower than Postgres. That is the double-edged sword from 2022 put into a number: Git semantics still cost real performance, but now it is a number teams can plan around. As for our question, whether database semantics would work better inside Git: we have not seen anyone seriously try.

The Bytebase#

Bytebase is an open source project that started in Jan 2021. It also shares some traits with the aforementioned products:

• Like Liquibase / Flyway / Sqitch, Bytebase uses migration-based approach to apply database schema changes.
• Like Prisma, Bytebase offers a fully-fledged web UI to conduct database development activities (schema, data change, SQL query).
• Like Atlas, Bytebase employs a modern tech stack, using Go instead of Java.
• Like PlanetScale / Neon, Bytebase focuses on developer experience. One example is the VCS integration, Bytebase provides a point-and-click wizard to configure VCS (the similar experience you find in Vercel / Netlify to link the code repository):

Bytebase is a jack-of-all-trades and the master of team collaboration:

• A standalone developer team can host a Bytebase workspace to manage database development activities.
• A DBA or platform team can also host a Bytebase workspace to be used by all the product teams in the entire organization.
• It has native VCS integration to streamline the code and database development together. Bytebase has concepts Project, Issue because it resembles systems like Jira, GitLab / GitHub.

It also has concepts Tenant, Environment to manage database changes for multi-tenant applications spanning multiple environments.

Bytebase also provides built-in schema review policies to enforce the schema standard across the whole engineering organization.

Bytebase is envisioned to be the counterpart of GitLab / GitHub to manage the database development aspect. It's positioned as a database governance platform for team collaboration.

How Bytebase compares against other tools:

*Though Bytebase uses migration-based approach, it records schema snapshot before and after the migration. Thus it also retains some state-based benefits such as drift detection

2026 check: Bytebase grew out of the "GitLab / GitHub for database" framing. It is now a database governance platform covering change, access control, and audit:

• The state-based workflow now exists alongside migration-based, for PostgreSQL and MySQL. The table above is the 2022 view.
• The Tenant concept was replaced by database groups, which roll one change out across many tenant databases.
• Schema review grew into SQL review with 100+ rules.
• An MCP server lets AI agents work under the signed-in user's permissions, capped by a workspace-wide access policy.

The Summaries#

Though the idea of Database as Code is not new, the trend and innovation have been much accelerated in the last 2 years:

• Commercial companies like GitLab, GitHub keep investing heavily in the Git-based DevOps infrastructure.
• Commercial companies like HashiCorp leverages the Git infrastructure and build innovative products like Terraform. The success of Terraform in turn popularizes the GitOps workflow and transforms the industry mindset from point-and-click systems into code-based systems.
• The proliferation of open source ecosystem. Coincidentally, all products in this space are either open source projects or their derivations.

• New building primitives were invented to challenge the status quo:
  • The invention of the V8 JavaScript Engine and Node.js opens the door for frontend engineers to interact with the databases directly. The flock of frontend engineers demands a high bar for developer experience.
  • Thanks to its pragmatic design and riding the wave of cloud computing, Go becomes a mainstream language and challenges the common wisdom of using Java to build backend applications. Especially in the cloud-native era, Go even dominates the market. For deploying a Java-based program, you need to install JVM first, which is not needed for Go. Just by adopting Go, tools like Bytebase and Atlas gain a competitive edge against Liquibase / Flyway. Not to mention the developer productivity boost offered by the language itself.
• Even though the database market is very mature, however, the market is too lucrative to ignore. Becoming the next Snowflake is every database practitioner's wide dream. New database systems were built and the bar has been raised higher and higher. Core database capability and performance are just table stakes, to differentiate, they have to compete for developer experience.

2026 check on these trends:

1. Git-based DevOps keeps winning, its biggest symbol less so. HashiCorp moved Terraform to the Business Source License in 2023, the community forked it as OpenTofu, and IBM completed its acquisition of HashiCorp in 2025. The GitOps mindset survived all of it.
2. "All products are open source" no longer holds. Liquibase is now Functional Source License, Atlas's standard build is commercial, and PlanetScale is a closed service. Open source became the on-ramp, not the business.
3. Go held its edge for new tools. Atlas and Bytebase are both Go; Liquibase 5.0 now requires Java 17.
4. Databases did compete on developer experience, and then on agent experience. Branching, instant provisioning, and scale-to-zero matter most when the user creating the database is an AI agent.

The iconic Evolutionary Database Design was written in 2016. Though the phrase "Database as Code" was not coined there, that article summarized the accumulated wisdom of applying Database as Code practice in the decade before.

The article also predicted a trend that a sizable DBA team will become less common. Nowadays, many serious engineering teams still need DBA's expertise, meanwhile, interacting with databases has also become developers' daily routine.

The power dynamics for managing database development have shifted over time, and the quest for better developer experience and efficient developer workflow is more demanding than ever.

It requires a delicate dance among the database systems, the database tools, and the industry mindset to conquer it. Database as Code is the critical puzzle and the timing couldn't be better to build in this space.

Four years later, the next shift is already here. AI agents now write migrations, not just queries. A migration file in Git, reviewed before it ships, is still the most reliable guardrail we have for that. Database as Code started as a way for humans to manage schema changes. It is turning into the way we let agents make them safely.