Pimp My IDE / garage dispatch
Back to garage
October 2, 2026 | Databases / agents

Make the database earn graduation.

A cheap database per agent is useful. Moving its work into a shared production system is a separate engineering job.

Do not treat "SQLite now, Postgres later" as a storage setting. Write the transfer contract before agent-made data becomes production data.

The acquisition promise needs a bridge.

Supabase announced that it is acquiring Turso. Supabase says its Postgres work will continue, Turso will continue its SQLite work, and the companies want one developer experience for cheap agent databases and larger applications.[1]

That is a product direction, not a migration contract. The announcement does not specify schema conversion, query compatibility, cutover behavior, or rollback. Until those parts exist and have tests, teams own the bridge.

A small database can be disposable. The data inside it may not be.

Isolation changes the cleanup job.

Turso describes one database per agent as a way to isolate state, delete one agent's data in one operation, and support local or cloud-connected work. The same guide names two poor fits: complex cross-agent queries and transactions that need strong atomic guarantees across several agents.[2]

That boundary matters. A per-agent file can simplify a scratch run. Shared reporting, billing, identity, and durable business records can pull the design toward a shared system. Count those shared operations before choosing the storage route.

Type names do not prove data parity.

SQLite uses flexible typing unless a table declares STRICT. Its documentation shows that a normal INTEGER column can retain text when a value cannot be converted without loss. STRICT tables reject values that cannot be converted to the declared type.[3]

PostgreSQL constraints reject rows that violate the declared rule. Its documentation covers checks, non-null rules, uniqueness, primary keys, foreign keys, and exclusion constraints.[4] A transfer test must inspect real rows, not only compare CREATE TABLE statements.

Graduate behavior, not a dump file.

Run the application workload against both systems before cutover. Save result sets, transaction outcomes, constraint failures, ordering assumptions, and time behavior. Test identity and permissions through the production route. Then rehearse backup, cutover, and rollback with a known revision.

  1. Inventory tables, types, defaults, constraints, indexes, extensions, and row counts.
  2. Replay representative reads, writes, conflicts, and failure cases on both systems.
  3. Map service identity, user identity, network access, and row-level rules.
  4. Restore a backup, run the cutover, compare results, and time the rollback.

The transfer case below writes the review sheet. It does not move data or verify either database.

Interactive makeover / database graduation transfer case

Load the transfer contract.

This replaces a vague "move to production" task. Four native switches connect a physical transfer bridge and write a review sheet with every evidence field left open.

Select review sections

These controls choose what the sheet will request. They do not inspect a database, run a migration, approve a cutover, or prove rollback.

Transfer loads
Transfer bridge

Bridge unloaded

0 of 4

Transfer sheet incomplete.

No review section is selected. Start with data shape.

A connected display means the sheet has four sections. It does not mean the source and target agree, data moved, a cutover passed, or rollback worked.

Graduation review sheet

The final state is template structure ready. Every bracketed field still needs a real source, target, revision, output, or result.

Sources read

Source log and evidence boundary
  1. Supabase, "Supabase is acquiring Turso", published and read October 2, 2026. This supplies the acquisition announcement, the stated continuation of Postgres and SQLite work, the one-million-databases-per-week claim, and the proposed path into the wider Supabase product.
  2. Turso, "Building AI Agent Databases: A Complete Guide to Database-per-Agent Architecture", published July 20 and read October 2, 2026. This supplies the vendor's database-per-agent patterns and its stated limits for cross-agent queries and atomic work across agents.
  3. SQLite documentation, "STRICT Tables", read October 2, 2026. This supplies the flexible-type and STRICT-table behavior used in the schema comparison.
  4. PostgreSQL 18 documentation, "Constraints", read October 2, 2026. This supplies the target-side constraint categories and rejection behavior.
  5. Hacker News discussion item 49934784, read October 2, 2026. We used the item as a discovery signal, not as evidence for product behavior.

Evidence boundary. We read the announcement, vendor architecture guide, and database documentation. We did not create a Turso or Supabase project, inspect a migration product, move data, compare workloads, or test rollback. The transfer case produces a planning sheet only.