A private Postgres for every app.
Not a datastore-shaped API. PostgreSQL 16 with real SQL, real migrations, and real indexes, isolated per project. It exists the moment your project does, on every plan, including free.
You ask in English. It ships SQL.
There is no dashboard to click through first. Your agent writes a migration file, deploys, and the schema is live. These files are in the exact shape the platform teaches it.
CREATE TABLE customers (
id BIGSERIAL PRIMARY KEY,
name TEXT NOT NULL,
email TEXT,
balance_cents INTEGER NOT NULL DEFAULT 0,
created_at TIMESTAMP NOT NULL DEFAULT now()
);
CREATE INDEX idx_customers_email
ON customers(email);
import { db } from 'hatchable';
export const access = 'member';
export default async function (req, res) {
const { rows } = await db.query(
`SELECT name, balance_cents
FROM customers
ORDER BY balance_cents DESC
LIMIT $1`,
[20]
);
res.json({ customers: rows });
}
Everything a database needs to be trusted.
The parts you would expect from a managed Postgres, minus the account, the connection strings, and the bill.
Plain SQL, end to end
Parameterized queries through db.query, with no ORM and no query-builder dialect in the middle. What your AI writes is what Postgres runs, and you can read every line of it.
SELECT is still SELECT. Twenty years of Postgres answers still apply.
Schema changes that ship with deploys
Migrations are SQL files in your project. They apply in order at deploy, each exactly once, forward only. The history of your schema is right there in the file list.
Renames and backfills follow a written safe-migration pattern your AI already knows.
All or nothing
Multiple writes run in a single Postgres transaction with db.transaction. Everything commits together or rolls back together, so partial failures never leave bad data behind.
Deduct the credits and write the audit row in one shot, or not at all.
Query it from the chat
The same connection that built your app can inspect the schema and run queries over MCP, before and after launch. Your data answers questions without a dashboard in between.
"What did we sell on Friday?" comes back as rows, in the chat.
Yours and only yours
Each project's database is private to that project. Different apps never share tables, and nothing you store is reachable from anyone else's code.
The chore tracker cannot see the client portal's rows.
Meaning, not just matching
Embeddings and vector storage live alongside your tables, with no separate vector database to run. Index notes or tickets and search by what they mean, using the AI key you already set.
The meeting archive finds the discussion you half remember.
Each person sees their own rows
Mark a table as private-per-person in one line of config and the platform installs the database policies that enforce it. The rule lives in Postgres, not in a query somebody has to remember to write.
In a shared expense tracker, nobody can read anyone else's entries.
A spreadsheet view, when you want one
Browse your tables, add and edit and delete rows by hand, and export any table, from the project console. No SQL required, and no separate database client to install.
Fix a typo in one row without opening a chat or a terminal.
The spec sheet, in plain terms.
migrations/, applied in filename order at deploy. Each runs exactly once.db.query with parameterized SQL, db.transaction for atomic writes.Numbers current as of August 2026 and enforced by the same table the pricing page renders from.
Say it like this.
No SQL required on your side. These are ordinary asks that turn into schema, queries, and indexes.
Asked and answered.
Is it really PostgreSQL?
Yes. PostgreSQL 16, one private database per project. Standard SQL, standard types, standard behavior. If you have used Postgres anywhere else, you already know this one.
Do I have to design the schema myself?
No. You describe the app and your AI writes the tables, indexes, and migrations, following patterns the platform hands it. Every migration is a readable SQL file in your project, and changing the schema is one more ask.
Can I look at my data directly?
Yes, two ways. The AI connection that built your app can run any query against it, and the project console gives you a spreadsheet view where you can browse tables and edit rows without writing SQL.
What are the limits?
The database is metered by table count and database time rather than by disk, so there is no "your database is full" wall. The free plan includes 50 tables per project and 2 hours of database time a month. Paid plans raise every number.
Can I take my data with me?
Yes. Keeping your data exportable is a commitment, not a feature. Ask your agent to export any table and it comes back as rows you can save as CSV or JSON, and your project's source files export alongside it.
More detail lives in the SDK reference and the pricing table.
Stop shopping for a database.
Connect the AI you already use, describe the app you want, and the database is simply there, schema and all.
Want the technical surface? The SDK reference covers db.query, migrations, and the rest.