September 28, 20265 min read

The Ptah Playground Now Runs PostgreSQL

play.ptah.run now runs PostgreSQL 18.3 in your browser tab through PGlite. A new scenario queries JSONB, then plans and applies a GIN index with Ptah.

Simon HartSolutions Engineer

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

Until today the playground ran Ptah against SQLite only. That was fine for adding a column, but most people who try Ptah deploy to PostgreSQL, and a lot of what they care about has no SQLite equivalent: JSONB, arrays, UUIDs, GIN indexes.

play.ptah.run now runs PostgreSQL 18.3 as well, through PGlite 0.5.8, in the same browser tab. Ptah is the same real CLI as before, now at v0.10.0, compiled to WebAssembly. Nothing is installed, and the database lives in memory.

Pick a database first

On your first visit the playground asks which database you want:

The “Choose a database” dialog. SQLite 3.53.4, the official SQLite
WebAssembly build, is selected; it loads when the playground starts and
supports SQLite file imports and versioned migrations. Below it, PostgreSQL
18.3 through PGlite 0.5.8: it downloads the PostgreSQL runtime when first
selected, supports JSONB, arrays, UUIDs and GIN indexes, and cannot import
SQLite files.

SQLite is there as soon as the page loads. PostgreSQL downloads the first time you pick it; on our connection it was ready about two and a half seconds after the click. The playground remembers your choice. A link can also pick one for you: ?engine=postgres opens the playground on PostgreSQL.

Switching databases resets the current scenario, and the dialog says so before you switch.

Which scenarios run where

Each scenario now says which databases it supports:

The scenario picker. “Change a schema, keep the data”, “Detect drift” and
“Free exploration” run on SQLite and PostgreSQL. “Versioned migrations” runs on
SQLite only. “JSONB and a GIN index” runs on PostgreSQL only.

Versioned migrations stay SQLite-only for a concrete reason. Ptah’s migration runner on PostgreSQL uses one database session to hold its lock and another to run the migrations, and PGlite provides a single session. The other scenarios don’t need two sessions, so they run on either database.

A walk through JSONB and a GIN index

This scenario starts with one table and two rows:

CREATE TABLE events (
  id UUID PRIMARY KEY,
  payload JSONB NOT NULL,
  tags TEXT[] NOT NULL,
  created_at TIMESTAMPTZ NOT NULL
);

The first step asks Ptah what it is talking to:

$ ptah db capabilities --db-url postgres://pglite/app
Dialect:            postgres
Server version:     18.3
Server product:     postgres
Banner:             PostgreSQL 18.3 (PGlite 0.5.8) on wasm32-unknown-emscripten, compiled by emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.74 (1092ec30a3fb1d46b1782ff1b4db5094d3d06ae5), 32-bit
Capability preset:  Postgres18 (postgres)
Preset source:      version-ladder
Support level:      certified
Release line:       18

Ptah reads the version from the server, as it would against any PostgreSQL, and picks its PostgreSQL 18 profile. The full output goes on to list every capability it will rely on when it plans.

The second step runs a query from the SQL pane, using a JSONB operator and an array operator:

SELECT id, payload->>'kind' AS kind, tags FROM events WHERE tags @> ARRAY['production'];

It returns the deploy event. Clicking a row in the Data pane opens the whole record, which helps with values too long for a table cell:

$A dialog titled “events · row 1”. id is 00000000-0000-0000-0000-000000000001, payload is {“kind”: “deploy”, “service”: “api”}, tags is {production,api}, and created_at is 2026-01-01 12:00+00.$

Now the schema change. The third step adds a GIN index to schema.sql, the file that describes the schema you want:

CREATE INDEX events_payload_idx ON events USING gin (payload);

Nothing in the database has changed yet. The fourth step asks Ptah for the plan without applying it:

$ ptah schema apply --schema-file schema.sql --db-url postgres://pglite/app --dry-run
Planned schema changes:
CREATE INDEX IF NOT EXISTS "events_payload_idx" ON "events" USING gin ("payload");

This is the same planner Ptah runs against a PostgreSQL server. We gave the same schema.sql and the same two rows to the native Ptah v0.10.0 binary and a PostgreSQL 18.6 server, and it printed the same plan, byte for byte.

The last step applies the change. Ptah prints the plan again and asks you to type YES, then the step checks for drift:

$ ptah schema drift --schema-file schema.sql --db-url postgres://pglite/app
No schema drift detected.

Both rows are still in the table, and the index shows up in the database list on the left.

A plan that knows it is out of date

After the apply, the Plan pane still shows the index statement, but it no longer describes the database. The pane says so:

The Plan pane after the apply. Its header reads “1 statement · stale”. A
warning says the plan is out of date because the database has changed since it
was produced, and that nothing will be applied. Below it are the refresh
command, ptah schema apply with –dry-run, a Refresh plan button, and the old
CREATE INDEX statement.

Refresh plan runs the dry-run command shown above it, through the same terminal. With the index in place, there is nothing left to do:

$ ptah schema apply --schema-file schema.sql --db-url postgres://pglite/app --dry-run
Schema is synced, no changes to be made.

It is also the quickest way to get a new plan after you edit schema.sql yourself.

Limits

The PostgreSQL database lives in memory, in this tab. Reloading the page discards it.
PGlite gives the playground one SQL session, so the versioned migrations scenario runs on SQLite only.
SQLite file import is not available while PostgreSQL is selected.

The earlier post on the playground update covers the guided steps, the editor marks and the phone layout, which work the same way on both databases. To try the new scenario, open play.ptah.run with PostgreSQL and pick JSONB and a GIN index.

Put Ptah to work

Example files

← All articles