Git-native database state management
DbState compares PostgreSQL database state with the desired state defined in Git. It helps teams capture database objects as files, review schema and reference-data differences, and prepare release artifacts without directly applying changes.
Database execution stays outside DbState.
Operating model
The Git repository is the source of truth for desired database state. DbState connects that repository to a target PostgreSQL database through explicit capture, comparison, and review workflows.
DbState reads PostgreSQL metadata and selected reference-data rows.
Explicit Database-to-Repository workflows write selected database objects or reference data into repository-managed files.
Repository-to-Database workflows compare desired state against the target database.
Supported differences may be selected in a Release Plan and prepared as review-only artifacts.
DbState does not execute generated SQL or directly mutate PostgreSQL during release workflows.
Product model
PostgreSQL Database
metadata and selected reference-data rows
DbState
capture, compare, diff, and plan
Git Repository Desired State
object files and reference-data YAML
Release Plan
selected supported candidates
Review-only Release Artifacts
database execution occurs outside DbState
PostgreSQL Database connects both directions to DbState. DbState connects both directions to Git Repository Desired State. The repository then leads to a Release Plan and review-only release artifacts.
Workflow model
DbState separates schema from reference data and separates repository file writes from read-only database comparison. The direction is part of the workflow, not an implicit side effect.
State type
Database to Repository
Purpose
Inspect supported database objects and write selected objects into durable repository files.
Output
Repository-managed object files
Safety boundary
Repository writes only. No PostgreSQL mutation. No automatic Git operations.
Repository to Database
Purpose
Compare repository-managed objects with a target database, inspect differences, build a Release Plan, and prepare supported review-only artifacts.
Output
Comparison results, Object Diff, Release Plan, and review-only artifacts
Safety boundary
Read-only database comparison. No direct apply. No generated SQL execution.
State type
Database to Repository
Purpose
Select reference-data tables, define row identity and comparison rules, preview YAML, and write approved repository files.
Output
Reference-data configuration and YAML files
Safety boundary
Explicit repository writes only. No PostgreSQL mutation. No automatic Git operations.
Repository to Database
Purpose
Compare repository-managed rows with PostgreSQL and inspect row-level state.
Output
Data Diff
Safety boundary
Read-only comparison. No automatic INSERT, UPDATE, DELETE, MERGE, or direct data apply in the current Private Beta.
Schema state
DbState stores one durable database object per repository file under controlled folders. The repository becomes the place where database structure can be reviewed beside application code.
Representative repository structure
database/
objects/
schemas/
extensions/
enums/
sequences/
tables/
indexes/
views/
materialized-views/
constraints/
functions/
triggers/
grants/
rls-policies/DbState does not automatically commit these files. Git history remains under user control.
Compare repository desired state with a target PostgreSQL database and identify different, database-only, repository-only, and in-sync objects.
Open full-size Schema Compare screenshotObject Diff
Comparison state alone is not enough. Object Diff exposes the repository and database definitions for a selected object so reviewers can understand the difference before deciding whether it belongs in a Release Plan or requires manual review.
Review target
The screenshot shows a real public.actor table difference with a repository-only nullable dbstate_demo_note column. DbState does not automatically resolve the difference.
Inspect repository and database definitions for a selected object before deciding how to handle the difference.
Open full-size Object Diff screenshotReference data
Slowly changing operational rows often carry application meaning but are poorly represented in schema-only workflows. DbState treats selected tables as repository-managed reference data when users explicitly configure them.
Common candidates
version: 1
tables:
- schema: public
name: country
keyColumns:
- country_id
ignoredColumns:
- last_update
maskedColumns: []This example identifies public.country by country_id and excludes last_update from comparison.
Data Diff
Repository-to-Database reference-data comparison is read-only in the current Private Beta. DbState shows row state so reviewers can decide how to handle differences outside DbState.
Database-only rows may still be referenced by foreign keys or carry historical meaning, so DbState leaves removal decisions for manual review.
Review repository-only, database-only, different, and in-sync reference-data rows.
Open full-size Reference Data Diff screenshotRelease Plans
Repository-to-Database schema comparison can lead into a Release Plan. Reviewers select supported candidates, inspect the handoff, and keep database execution in their normal release process outside DbState.
Select supported release candidates and review the planned handoff before any database execution occurs outside DbState.
Open full-size Release Plan screenshotPostgreSQL coverage
DbState Private Beta understands a meaningful set of PostgreSQL object types needed for application and database engineering workflows.
Current boundaries
Current Private Beta boundaries are product decisions. DbState is focused on local PostgreSQL review workflows where the user remains in control of Git history and database execution.
Private Beta runs as a local Windows developer workflow.
DbState does not automatically add, commit, push, pull, fetch, or tag.
Generated artifacts are reviewed and executed through the team's normal database release process outside DbState.
Hosted workflows, shared workspaces, approval systems, and server-based collaboration are not part of the current Private Beta.
The current product focuses on PostgreSQL. The database-state model may expand to additional relational database engines over time.
Private Beta
The current Private Beta is intended for developers, database engineers, and technical teams actively managing PostgreSQL schema or reference-data changes through Git.