Databases that bill like utilities
Why pooled PostgreSQL with a platform-funded capacity floor and per-database usage metering fits small and spiky workloads better than resold instances.
Picking a database instance size has always meant guessing at a shape of traffic you don’t fully know yet. Too small and it falls over during a launch spike; too large and you’re paying around the clock for capacity your app touches for a few minutes a day. Managed Databases on SetCloud removes that product choice: client databases share one auto-scaling PostgreSQL pool and are metered from measured activity rather than a resold instance size.
Always ready, without billing the floor
A database attached to your project is not a dedicated cloud instance. It is a logical database and scoped role on shared capacity that grows with aggregate demand. The pool keeps a shared readiness floor available so a quiet database does not wait for a cold start, but SetCloud subtracts that floor before allocating compute usage to clients. Connection details reach your app as DATABASE_URL; the pool and private proxy remain an implementation detail. See connect to your database for the injection contract.
There is no size or engine to pick before you start. A fixed-instance database asks you to guess a shape before you have traffic to measure. The pooled model lets the first deploy and later traffic share the capacity available to the account without turning a provider database SKU into a SetCloud product tier.
Metered per database
Rather than one number for “the database,” usage splits into three separate meters, each on the published rate card at /pricing:
- Compute — client-attributable capacity above the platform-owned floor, billed per capacity-unit-hour.
- Storage — your data at rest, billed per GB-month. Storage bills continuously regardless of query activity, because the data has to live somewhere whether or not anyone’s querying it right now.
- I/O — the read and write requests the database actually serves, billed per request volume.
Splitting the meter keeps a busy database priced on what it does while the shared readiness floor and proxy remain platform overhead. Exact current figures for all three client meters are on the Managed Databases row of the rate card.
Keeping the three meters separate also keeps the bill legible. A single blended number for “database usage” would hide which behavior is actually driving cost — a query-heavy app and a storage-heavy one could land on the same total for entirely different reasons, and neither owner would know which lever to pull. Three meters means a spike in your bill traces back to a specific cause: more queries, more data at rest, or more read/write volume, not an opaque aggregate you have to reverse-engineer.
Why usage beats instance pricing
Fixed-instance pricing makes a specific bet: that your workload is steady enough that a provisioned size is close to correct most of the time. That bet is fine for a handful of workload shapes and wrong for a lot of real ones. A side project that gets traffic in bursts around a launch or a newsletter send. A staging database that’s queried heavily during a sprint and untouched for the two weeks after. An internal tool a team opens twice a week. All three would be paying for a fixed instance around the clock under instance pricing, sized for their busiest moment and idle the rest of the time.
Usage-based metering doesn’t require picking a client-facing size. A small, spiky workload pays for its measured compute above the shared floor, storage, and I/O. A steadier workload accrues steadier usage without a manual resize step or a dedicated instance tier to outgrow.
On your invoice
All of it — compute, storage, I/O, across every database on your account — rolls up into a single Managed Databases line on your monthly statement. You don’t get a separate line per meter or per database; you get one number for the pillar, with the itemized breakdown available if you open the invoice for detail. That’s consistent with how every other pillar bills on SetCloud: one credit balance, one statement, pillar-labeled lines rather than a pile of line items that need translating into what they actually paid for.
More on how the roll-up works: how database usage is billed. Product overview: /products/databases. Current rates: /pricing.