Data API
buildingA Postgres database of your own, created in seconds, with a connection string you paste into your app.
Database
A Postgres database per project. You get a connection string; your application talks to it directly.
We are not in the middle of your queries. There is no proxy of ours between your app and the database, no per-query overhead we added, and no API of ours to learn — it is Postgres, and everything you already know about it applies. What we do is create it, keep it running, hand you the credential, and put it on the same invoice as the rest of your project.
Every example on these pages uses two shell variables. Set them once and the rest pastes straight into a terminal:
export BASE="https://<your-deployment>"
export SK="sk_live_…"The pages
| Create a database | What you get, where it lives, what starts costing |
| Connecting | Two connection strings and which to use |
| Connection details | GET /v1/data/_connection, for deploys |
| Running migrations | Which endpoint, and why it matters |
| Sleeping and waking | Scale to zero, cold starts, autoscaling |
| Replacing the password | Rotation and what it breaks |
| Limits | Quotas, suspension, and what is not built yet |
| Branches and browsing | Copy your database, and look inside it |
| Backups and restore | Seven days of history, and a restore that takes seconds |
Your database is your own
Not a schema in a shared cluster, not a row-level-security policy trusted to separate you from somebody else: a separate Postgres database with its own compute, in a region you choose.
Isolation by convention means every query in somebody's codebase has to remember
a where clause, and the one that forgets is a breach. Isolation by database
means two customers' rows are never in the same query scope, so there is no
clause to forget.
What follows from it:
- You are the owner.
CREATE EXTENSION,CREATE SCHEMA, roles of your own. - Nobody else's traffic is your problem. Your compute is yours.
- Any Postgres tool works, because it is Postgres. No driver of ours, no dialect, nothing to learn.
One endpoint, and that is deliberate
There is exactly one API call here — connection details — because after that you are talking to Postgres, not to us. We are not a proxy in front of your queries: no hop we added, no latency we own, nothing of ours to be down.
What it costs
| Storage | $1.00 per GB-month |
| Point-in-time restore | $0.50 per GB-month of history |
| Compute | $0.30 per compute-hour, only while it is awake |
| Transfer | $0.25 per GB read out over the internet |
| Minimum | $5 a month per project with a database |
A GB-month is measured continuously, not sampled. Half a month at half a gigabyte is a quarter of a GB-month — so deleting data lowers the bill from that moment rather than at the next reading, and a database that doubles in size mid-month is charged for what it actually held. Gigabytes are decimal (1,000,000,000 bytes), which is how the storage underneath is metered.
The minimum is a floor, not a base fee: a project using $8 pays $8, not $13.
Usage is read from the database's own consumption figures once a day and appears on your usage and billing page like everything else.
You can remove it again from the same page — see limits for what that destroys and what it does not.
Compute is billed only while the database is awake, and it sleeps five minutes after the last connection — so a quiet project pays for what it stores and very little else. Sleeping and waking has the details and the one trick not to try.
Limits
Every database is created with a ceiling on compute and size, so a runaway query is a suspended database rather than a surprise invoice. All of them are per project and raisable: see limits, which also lists what is not built yet.