A Postgres database of your own.
$5 a month.
Serverless Postgres for the sites and apps we build for you. One isolated database per site — not a slice of a shared one — provisioned, monitored, and tuned by us. A flat $5 base covers what a well-built site uses. If you ever go over, the meter is public, the rate is fixed, and there's a cap.
One number, and what it covers.
- + 20 CU-hours of compute / month
- + 1 GB storage
- + Isolated database per site
- + Provisioning, wiring, monitoring
- + Prerendering + query tuning
- + Usage cap, on by default
- + Plain Postgres connection string
- + Real human if something breaks
Most sites we build use 6–12 CU-hours a month — well inside the 20. Overage starts only above the allowance, at $0.40 per CU-hour and $2 per GB-month, and the cap stops compute at 60 CU-hours unless you ask for more.
Running a VPS with us? Postgres is already on the box. This is for application hosting sites, where the app runs stateless and needs a database that isn't tied to one server.
What a CU-hour is, and why you rarely pay for one.
CU-hours
A compute unit is a slice of database CPU and memory. Your database sleeps when nothing is talking to it and wakes on the first query. You pay for awake time, in CU-hours. Asleep, it costs nothing.
Why a good site barely registers
A prerendered site wakes the database when content changes or someone hits a genuinely dynamic page, not on every visit. Six to twelve CU-hours a month is typical. 20 is the allowance.
What burns compute
Pages rendered on every request that could have been static. Timers or jobs that poke the database. A CMS someone works in all day. The first two are our job to prevent; the third is real usage.
Whose fault overage is
Honest answer: usually ours. If your database trips its allowance, the first thing we check is our own build — routes that should be static, revalidation set wrong. When that's the cause we fix it and you aren't billed for it. Overage is for real growth: more traffic, a bigger catalog, heavy admin use.
The cap
Every database ships with a cap at 60 CU-hours — three times the allowance, a $21.00 month. As usage climbs you hear from us. Want it higher? Say so. If a database ever reaches its cap it pauses until you raise it or the month rolls over: a pause you were told about, not a bill you weren't.
Storage
Content sites are tens of megabytes. 1 GB is included; past that it's $2 per GB-month, rounded up to whole gigabytes. Storage isn't capped — it's a level, not a rate, and it moves slowly.
A database, and the people who watch it.
Isolated per site
Every site gets its own database, its own credentials, its own limits. Nobody else's traffic is in your database, and nobody else's bad day is either.
Provisioned by us
We create it, wire the connection string into your app, and set the limits. You never touch a console you didn't ask for.
Monitored by us
Compute, storage, and wake-ups read daily. Usage alerts go to us first, then to you if it matters. Your dashboard shows the same numbers your invoice uses.
No surprise suspensions
Free database tiers stop cold when you hit their quota, mid-month, with no warning. Yours doesn't — it's on a paid plan, with a cap you control and hear about first.
Built to stay cheap
The prerendering and query work that keeps a site inside its allowance is part of the service, not a change order. Cheap is a thing we build, not a thing you're charged for.
Plain Postgres
A standard connection string. Any driver, any ORM, any Postgres tool you already use. Nothing proprietary to migrate off of if you ever leave.
How it's measured, in plain English.
How usage is measured
Compute is metered upstream per database, in compute-unit seconds, and summed over the calendar month (UTC). Storage is the month's average of daily peak size. We read both daily. Only the part above the allowance is ever billed, rounded up to whole CU-hours and whole gigabytes.
When you hear from us
As a database approaches its allowance, and again before it nears its cap. Before any overage lands on an invoice we've looked at it ourselves — and if the cause is our build, it doesn't land.
What the cap does
A hard ceiling on compute, set per database, on by default at 60 CU-hours. Raise it any time by asking. If it's reached, the database pauses rather than the bill growing, and resumes when the cap is raised or the month rolls over.
Where it runs
Your database runs on a serverless Postgres provider we resell, in a project that is yours alone. We monitor it, but we don't operate their hardware — so we don't publish an uptime number for this tier. When it has a bad day, you hear about it from us, with what happened.