November 9, 20269 min read

Atlas vs Ptah: An Open Source Choice for Schema Management

Compare Atlas and Ptah by the database jobs they solve: plans, approvals, migrations, drift, OCI distribution, plugins, and rollout boundaries.

Nathan BrooksTechnical Writer

Ptah helps you plan, review, and apply database migrations. Try in your browser

Ptah gives you an open-source way to plan and run schema changes, review the exact SQL, check for drift, and automate migrations in your own infrastructure. You can use its CLI or embedded Go runner, publish versioned schema and migration artifacts to an OCI registry, run its Kubernetes Operator and Console, and extend database support through separate provider plugins. The Ptah core and its YDB, Spanner, and DuckDB plugins are MIT-licensed. There is no Ptah Pro edition to unlock the workflows in this article.

Many schema-management jobs listed under Atlas Pro have an open-source Ptah solution. The comparison below also identifies two concrete gaps.

This article checks Ptah 0.25.0 against source-built Atlas Community Edition (CE) 1.3.0 as of November 9, 2026. The reproducible SQLite run records both binaries, commands, and outputs. Claims about Atlas Pro come from its published feature matrix, not from that CE run. Operator and Console have independent versions, discussed separately.

The open-source choice

Atlas CE is open source under Apache 2.0 and covers inspection, diffs, declarative changes, and versioned migrations. Atlas’s downloadable standard distribution includes proprietary components under its MSA, while its feature matrix puts many advanced workflows in Pro. CE still has basic lint rules. A free-to-download Atlas build and the source-built CE are different licensing propositions.

Ptah’s schema planning, linting, checks, testing, drift detection, and extension points are open source. You can keep the workflow local or automate it with your own CI, registry, and Kubernetes cluster. The separate provider tutorial shows how to add an engine without putting its driver in Ptah’s main binary. It can read the catalog, model engine-specific objects, plan and execute changes, and supply analysis rules. Its author can develop and release it in a separate repository. The three official plugins demonstrate this model; they are not an allowlist for third-party providers.

What a saved plan prevents

Consider a SQLite table with id and email. The desired schema adds a nullable created_at column. These are the exact files used in the recorded run:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL
);

The desired schema adds a nullable timestamp:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL,
    created_at TIMESTAMP
);

On a disposable database, Ptah saved a plan with one statement:

sqlite3 ptah.db < baseline.sql
ptah schema plan --db-url "sqlite://$PWD/ptah.db" \
  --schema-file schema.sql --save --name add_created_at

Ptah printed the change and wrote add_created_at.plan.json:

Planned schema changes:
ALTER TABLE "users" ADD COLUMN "created_at" TIMESTAMP;
Plan saved to file://add_created_at.plan.json

The plan records a fingerprint of the schema Ptah observed. To test its boundary, we made a second database from the same baseline, planned the same change, then independently added a note column before applying its saved plan:

sqlite3 stale.db < baseline.sql
ptah schema plan --db-url "sqlite://$PWD/stale.db" \
  --schema-file schema.sql --save --name stale
sqlite3 stale.db 'ALTER TABLE users ADD COLUMN note TEXT;'
ptah schema apply --db-url "sqlite://$PWD/stale.db" \
  --plan stale.plan.json --auto-approve

The last command exited 2 with pre-planned migration is stale. It did not add created_at: the reviewed plan no longer described the target database. Ptah asked for a fresh plan against the new state. For stronger authorization, the native approval flow signs the exact plan bytes and makes apply --require-approval check an allowed signer; the schema fingerprint is a separate apply-time check.

The unchanged ptah.db accepted its saved plan, and ptah schema drift reported no drift. Atlas CE’s schema apply --dry-run also previewed the column addition, but its schema plan command was unavailable in the CE build. The supporting run includes the Atlas CE dry run and apply, both database inspections, and the complete Ptah output. This example proves a specific Ptah safety property; it does not benchmark either product or test Atlas Pro.

Workflow coverage

Each row compares a user task, Ptah’s solution, and a practical limit where one affects adoption. Atlas editions follow its feature matrix; Ptah links point to the 0.25.0 tag unless another component is named.

Design and verify changes

Task	Atlas edition	Ptah solution	Verified boundary
Inspect, compare, and apply a desired schema	CE	Inspect, compare, and apply with the native CLI.	Object coverage varies by engine.
Keep a migration history	CE	Generate and apply versioned migrations.	—
Review a specific change before execution	Standard/Pro (CE has a dry run)	Save a fingerprint-bound plan and refuse a changed target.	—
Edit planned SQL	Pro	`ptah-compat schema plan --edit` opens SQL in `$VISUAL` or `$EDITOR` before publication. The compatibility command documents the edit and safety reassessment.	`--edit` is a compatibility CLI option. Native `ptah schema plan` has no such flag.
Check preconditions for versioned migrations	Pro	SQL assertions check data-state conditions before a migration runs.	Assertions do not authorize who may run `migrations up`.
Authorize a saved direct-schema plan	Pro	`schema approve` signs the plan bytes. `schema verify-approval` checks allowed signers. `schema apply --plan ... --require-approval` enforces the signature.	This SSH approval gate does not apply to ordinary `migrations up`.
Detect schema drift in CI	Pro	Drift checks return a pipeline-usable result.	The provider must be able to observe the relevant database objects.
Lint migrations and add rules	Pro for advanced and custom rules (basic CE rules exist)	Local linting and custom rules.	—
Bootstrap from migration checkpoints	Pro	Cumulative checkpoints initialize a fresh database.	—
View and share a schema	Pro	Mermaid, DOT, and SVG diagrams, self-contained HTML documentation, and a read-only browser view of live drift via `schema serve`.	The live page defaults to localhost and has no authentication.
Test schema and migrations	Pro	Run test cases against a disposable database.	—

Data, distribution, and operations

Task	Atlas edition	Ptah solution	Verified boundary
Manage database access as code	Pro	PostgreSQL roles, grants, and RLS MySQL/MariaDB roles SQL Server RLS through `SECURITY POLICY`	MySQL/MariaDB role management does not manage users or role attributes. SQL Server’s supported RLS declaration is engine-specific.
Manage reference rows	Pro	Declare and reconcile managed reference data.	This is for declared reference rows, not arbitrary application data.
Run data scripts	Pro	`ptah-compat script query`, `exec`, and `loop` provide reads, conditional transactional changes, batches, and result masking in the compatibility CLI implementation.	It supports a defined script grammar, not every Atlas script expression. `loop` commits batches separately.
Publish and pin schema or migration artifacts	Standard/Pro registry features	OCI artifacts distribute schemas and migrations with digest pins and related reports.	Digest pins identify bytes, not the publisher. Ptah does not verify artifact signatures.
Apply migrations sequentially to several targets	CE	`ptah-compat migrate apply` runs selected targets in sequence.	Stops at the first failure. Earlier targets may already have changed.
Manage a canary or staged rollout across target groups	Pro	No managed cross-target rollout workflow yet. The Operator reconciles individual database resources.	Tracked in Ptah #5829.
Find unsafe access configuration	Pro security features	`schema security` analyzes roles, privileges, owners, and policies.	It is an access-model analysis, not a CVE scan.
Detect known engine or extension vulnerabilities	Pro security scan	No equivalent CVE matching workflow today.	Not available: version and advisory scanning is tracked separately.

Review and approve changes in Kubernetes

With the tested Operator 0.2.9 and Console 0.3.2 pair, an operator can review the integrity-checked SQL, approve a specific plan, watch its execution, and inspect the history of decisions. The Console shows diagnostics and exports its approval audit as CSV. Kubernetes admission records the approver’s identity under RBAC; the Operator’s approval object binds the plan UID and fingerprint.

Version pairing matters: Operator 0.2.10 has a verified Ptah 0.23.0 executor, while Console 0.3.2 was tested with Operator 0.2.9. The Console update for newer plans is still open. Pin and test the pair you deploy; the 0.25.0 CLI findings above do not automatically describe the Operator executor.

Database plugins and a direction of its own

Ptah’s 0.25.0 support matrix lists PostgreSQL, SQLite, MySQL, MariaDB, SQL Server, CockroachDB, YugabyteDB, ClickHouse, and Oracle in the core, plus separately installed YDB, Spanner, and DuckDB plugins. A database name is only the start of a coverage check: examine the engine page for the objects and operations your schema uses. Provider architecture, the tutorial, and conformance tests give a third-party author a route from first build to a checked provider. Go has the ready SDK; another language can implement the protocol with more bootstrap work. Test and pin compatible Ptah and provider versions.

Changing an embedding model also means migrating the persistent vectors it produced. Ptah’s persistent inference state migrations manage preparation, verification, cutover, and rollback in supported PostgreSQL/pgvector and YDB workflows. Ptah orchestrates the state transition; the embedding endpoint remains external.

Moving an Atlas project

ptah-compat offers an Atlas-shaped CLI for supported commands and project settings; native ptah has its own command tree. The adoption guide starts with an existing atlas.hcl and uses ptah project adopt --check to classify settings as native, compatibility-only, or unsupported. Supported Atlas migration files and revision history can be retained, so an existing database need not replay its migrations. Full Atlas HCL compatibility is not promised.

An atlas:// URL is an Atlas Cloud protocol and does not resolve as a Ptah artifact. Publish or fetch through Ptah’s OCI workflow when moving that part of a pipeline.

The Atlas handover example follows a real migration history and checks a PostgreSQL view. The wpmgr case study shows a repository where an RLS policy mattered. Those cases test narrower boundaries than this decision guide; use them when they match your project.

Where to start

Ptah is a strong fit when you need source access across planning, validation, approvals, drift checks, deployment automation, and database extensions. Before adopting it, check your engine’s object coverage, the commands your project actually uses, and the version pairing of any provider, Operator, and Console components. The support matrix and quick start are good first stops.

Keep an existing Atlas setup when a specific Atlas Cloud workflow, atlas:// integration, unsupported Ptah engine or object, or its managed staged rollout is a requirement you cannot replace. Atlas CE may also be sufficient if its open core is all you need. A team that wants migrations inside its Go program should examine Ptah’s embedded migration runner; it does not require a separate schema process. Start with the SQLite example above, then test a representative plan on a disposable copy of your own database.

Put Ptah to work

Example files

← All articles