Database as CodeVersioned. Reviewed. Deployed. Audited.
Database schemas live in version control. Schema changes flow through pull requests and CI/CD — the same path as application code.
Database as Code architecture
Two approaches. One source of truth.
State-based (declarative)
The full schema lives as one file in version control. Tools diff the file against the live database and reconcile. Single source of truth, simple to describe, harder for data migrations. The Infrastructure-as-Code default.
Migration-based (imperative)
Each schema change is a versioned migration script. Migrations execute in deterministic order. Reviewable per-change, replayable in CI/CD, mainstream in Database-as-Code.
Database as Code guide
Read in order.
- 01
Start with the foundation
Database version control covers collaboration, history, deployment, rollback, and GitOps integration. The features that distinguish it from ad-hoc DDL.
- 02
Pick your approach
State-based or migration-based. The trade-offs that drive the divergence between Infrastructure as Code and Database as Code.
- 03
Apply the best practice
How teams actually run database-as-code in production. Practices that hold up at scale.
Database as Code approaches
Three flavors. One outcome.
State-based
Declarative. Full schema in one file. Tools reconcile the database to the desired state.
Read →Migration-based
Imperative. Versioned change scripts. Deterministic ordering, replayable in CI/CD.
Read →Hybrid
Migration scripts for changes, state file for the source of truth. Best of both.
Read →
Database as Code in Bytebase
Schema in code. Changes governed.
Bytebase connects GitHub, GitLab, Bitbucket, and Azure DevOps to the database. Schema changes flow as pull requests. Each change runs SQL review, lint, and policy enforcement before deployment. Migration history is captured automatically in both Bytebase and the VCS.
One workflow. Every database.
Database as Code questions
Common questions.
- What is database as code?
- Database as code is the practice of managing database schemas in version control, the same way application code is managed. Schema definitions and change scripts live in a Git repository. Changes go through pull requests, code review, CI checks, and automated deployment. The result: a versioned, reviewable, replayable history of every database change.
- State-based or migration-based — which should I choose?
- Migration-based is the mainstream choice for database as code. Each schema change is a versioned script applied in order — reviewable per change and replayable in CI/CD. State-based stores the full schema as one file and reconciles the database to match; this is how Infrastructure as Code (Terraform, Kubernetes) works, but it's harder to express data migrations. Many teams use a hybrid: migrations for changes, a state file as the source of truth.
- Does database as code work with my existing CI/CD?
- Yes. The same Git workflow that runs application CI/CD also runs database CI/CD. GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure DevOps, Argo CD, and Flux can all execute schema migrations as part of the deployment pipeline — typically with a SQL review or lint step before applying.
Every post in the series.
- 01
What is Database Version Control?
Foundations: collaboration, change history, deployment, rollback, GitOps integration.
- 02
Database Version Control, State-based or Migration-based?
The two approaches and the trade-offs that drive the IaC vs DAC divergence.
- 03
Database as Code — the Good, the Bad and the Ugly
Why DAC works, where it stalls, and what's missing for wider adoption.
- 04
The Database as Code Landscape
Tools, integrations, and the practical path to running schema in version control.
- 05
Database Version Control Best Practice
How teams run database-as-code in production. Practices that hold up at scale.