One that sleeps, one that never does.
Managed PostgreSQL, MySQL, and MongoDB. Run a serverless Postgres that suspends its compute when nothing is querying it, or a dedicated cluster sized for capacity you always want available. Backups, patching, and failover are handled either way.
- 2 kinds of database
- 3 engines
- 14–18 Postgres versions
- Included backups and restore
# woken by the first query$ psql postgresql://orders-prod…/orderspsql (18.1)$ SELECT count(*) FROM orders; count ------ 48211
- PlanGrowth · 2 CU
- Compute this month112 / 375 CU-h
- Storage4.1 / 25 GB
IDLE COST
Suspends
Serverless compute stops between queries
ENGINES
3
PostgreSQL, MySQL, MongoDB
RESTORE
7days
Point-in-time, on the largest plan
FAILOVER
Automatic
Up to two standby nodes
One decision, then two settings
The first choice is about idle time
Both kinds are fully managed and both hand you a connection string when they finish. What separates them is what happens when nobody is querying — and that is the question worth answering first.
- 01
Pick how it should idle
Scales to zero suspends the compute when nothing is querying it, so a quiet database costs almost nothing from its allowance. Always-on buys fixed capacity that never sleeps.
- 02
Choose the engine, version, and region
Serverless is PostgreSQL 14 through 18, newest by default. Always-on adds MySQL and MongoDB, a node type, and up to two standby nodes. The price is shown before anything is created.
- 03
Copy the connection string once
When provisioning finishes you get the host, database, user, and a ready-made connection string. The password is shown once — put it in the secrets manager before you leave the page.
What a database includes
Managed, and still sized by you
Cosmoner runs the backups, the patching, and the failover. Capacity, durability, and where the data lives stay decisions you make per database.
Compute that stops when you do
A serverless database suspends after its idle timeout and wakes on the next query, usually well under a second. Nothing is lost while it sleeps and the connection string does not change.
Wakes on the next query
Three engines, versions you choose
PostgreSQL either way, plus MySQL and MongoDB on always-on clusters. Serverless offers PostgreSQL 14 through 18 so a framework or extension that is not ready for the newest is not a blocker.
PostgreSQL · MySQL · MongoDB
A limit, not a surprise invoice
A serverless plan's allowances are hard limits. At the cap the compute is suspended and the data is preserved — you are never billed past the plan you chose.
Warned at 80%
Standbys that fail over on their own
An always-on cluster takes up to two standby nodes. A standby replicates the primary and takes over automatically if it fails, with nothing to trigger by hand.
Up to two standbys
Point-in-time restore, included
Backups and patching are handled for you, and every serverless plan carries a restore window you can rewind to. The window is part of the plan rather than a paid extra.
Up to 7 days back
Read your data without a client
Serverless databases have a Data tab for paging through tables and running a single SELECT. It is read-only and runs in a read-only transaction, so nothing typed there can change the database.
Read-only by design
Scales to zero
You buy a rate and a total, not a server
A serverless plan sets two separate numbers: a compute ceiling the database autoscales up to, and a monthly compute allowance it draws from while it is awake. Because they are separate, the same allowance stretches differently depending on the size actually running.
- One CU is one vCPU with 4 GB of memory — the rate. One CU-hour is one CU running for an hour — the total.
- A calendar month is about 730 hours, so a database running continuously at 1 CU spends roughly 730 CU-h.
- The compute autoscales between a floor and the ceiling, so a mostly idle database spends what the work costs, not the plan's maximum.
- Meters for compute and storage are read live on the database's page and turn amber past 80% of a limit.
# the same allowance, three sizes0.25 CU → 4 h of uptime per CU-h1 CU → 1 h of uptime per CU-h2 CU → 30 min of uptime per CU-h# awake 2 h a day at 0.25 CU≈ 15 CU-h a month
Serverless plans
Four tiers, and what separates them
Every plan includes storage, a compute allowance, and point-in-time restore across the window shown. The plan picker carries the current monthly price for each one.
Hobby
A side project or a branch database that is quiet most of the day.
- Ceiling
- 0.25 CU
- Allowance
- 35 CU-h
- Storage
- 3 GB
- Restore
- 1 d
- Sleeps after
- 5 min
Starter
Development and staging, or a small production app with real but modest traffic.
- Ceiling
- 1 CU
- Allowance
- 145 CU-h
- Storage
- 10 GB
- Restore
- 1 d
- Sleeps after
- 5 min
Growth
A production workload with busy stretches that should not be throttled by the ceiling.
- Ceiling
- 2 CU
- Allowance
- 375 CU-h
- Storage
- 25 GB
- Restore
- 3 d
- Sleeps after
- 10 min
Scale
The tier an always-on workload lands on — its allowance clears a full month at 1 CU.
- Ceiling
- 4 CU
- Allowance
- 950 CU-h
- Storage
- 75 GB
- Restore
- 7 d
- Sleeps after
- 30 min
The idle timeout is the number most likely to explain a usage figure you did not expect — every open connection holds the compute awake for at least that long.
Always-on
Capacity you are buying, not usage you are metering
An always-on cluster is dedicated and sized by you. There is no sleeping, no allowance, and no usage cap: the monthly price is the same whether the database is busy or idle, which is exactly what you want under steady traffic.
- PostgreSQL, MySQL, or MongoDB, on a node type chosen for the shape of the workload.
- Up to two standby nodes, each replicating the primary and each billed at the size's price.
- Extra disk beyond the size's included amount, added in 10 GB increments per node.
- Put the cluster in the region the app queries from — a cross-region query pays the round trip every call.
- EnginePostgreSQL 17
- Node typeGeneral Purpose
- Size4 vCPU / 16 GB
- Nodes1 primary + 1 standby
- Extra storage+20 GB
# priced before anything is created2 nodes billed at the size's price
Four shapes of node
Sized for what the workload runs out of first
A cluster is bound by CPU, by memory, or by disk long before it is bound by all three. The node type is where you say which one.
Basic
Development and light production, where the cluster is mostly waiting rather than working.
Shared CPU
General Purpose
Steady production traffic that wants predictable CPU rather than a shared slice of one.
Dedicated CPU
Memory-Optimized
Large working sets, where keeping the hot data in memory is what decides query time.
8 GB per vCPU
Storage-Optimized
Data-heavy workloads that outgrow the disk long before they outgrow the CPU.
Large NVMe disks
Where it runs
Next to the app that queries it
Region is picked when the database is created and cannot be moved afterwards, so pick the one your workload runs in. Serverless Postgres is offered in the regions below; always-on clusters have their own list, which depends on the provider you choose.
- eu-central-1Frankfurt
- eu-west-2London
- us-east-1N. Virginia
- us-west-2Oregon
The region list in the create flow is the source of truth, and narrows to what the engine and provider you picked actually offer.
One project
What it plugs into
A database is billed on the project's subscription alongside the apps that query it, behind the same roles and the same API keys.
What it costs
A plan, or a node — never a per-query line
Serverless is a fixed monthly plan whose allowances are hard limits, so it cannot bill past what you chose. Always-on is a fixed monthly price per node for the capacity you reserved.
- Scales to zero
- from USD 5 / month
- A fixed monthly plan with a compute ceiling, a compute allowance, and storage included. There is no per-query or per-hour line on top of it.
- Always-on
- Per node
- One monthly price per node for the vCPU, memory, and included disk you picked. The same price whether the database is busy or idle.
- Standby nodes
- Per node
- A standby replicates the primary and takes over automatically if it fails. Each one bills at the size's price, so a two-node cluster costs twice a one-node cluster.
- Extra storage
- Per GB · mo
- Always-on only, in 10 GB increments per node, on top of the disk the size already includes. Serverless storage is part of the plan and is not sold separately.
- Backups and restore
- Included
- Automated backups, patching, and point-in-time restore across the plan's window are part of the price rather than an add-on.
Every plan and size shows its monthly price in the create flow, and a database created mid-month is prorated from the day it is created.
Questions worth answering up front
Compute units, idle timeouts, plan changes, and connecting are covered in the Databases guide.
- Scales to zero, or always-on?
- Scales to zero for development, staging, side projects, and anything with quiet stretches — an idle database barely touches its allowance. Always-on for steady production traffic, latency-sensitive endpoints, or any engine other than PostgreSQL. Bursty and cron-driven workloads usually still suit scales to zero, as long as you account for the idle timeout.
- What are CU and CU-h?
- A compute unit is one vCPU with 4 GB of memory, and it measures how fast the database can go at any one moment. A compute unit hour is one CU running for one hour, and it measures how much compute the database has used over the month. A plan sets both: a ceiling on the rate and an allowance on the total. Because they are separate, the same allowance stretches four times as far at 0.25 CU as it does at 1 CU.
- Why is my usage higher than my query volume?
- The idle timeout is almost always the answer. Any open connection keeps the compute awake, and every visit holds it up for at least the full timeout after the last query. A database touched once every ten minutes by a health check is, in practice, awake all the time. Look for a pooler or ORM holding an idle connection, an uptime check hitting an endpoint that queries, or a cron job running more often than the timeout is long.
- What happens when a plan's limit is reached?
- The compute is suspended and stops accepting queries. Nothing is deleted and your data is preserved. Compute is a per-period allowance, so a compute-suspended database comes back on its own at the next billing period, or immediately if you move up a plan. Storage does not reset — a database at its storage cap stays suspended until you free up space or move up, which is deliberate: writes stop before storage can run away.
- Can I change plan or size later?
- Yes. The database's detail page lists every plan next to your current one, tells you what changes before anything is charged, and applies the change immediately, prorated against your billing period. Moving up raises the limits straight away and restarts a database that was suspended for its compute allowance. A smaller plan is unavailable while the database holds more data than it includes.
- Can I upgrade a database to a newer major version?
- Not in place. The PostgreSQL major version is fixed for the life of a serverless database, so moving to a newer one means creating a new database and migrating your data into it. Pick an older version only when something you depend on is not ready for the newest.
- What if I lose the password?
- Rotate it from the database's detail page and update whatever was using the old one — rotating invalidates the previous password immediately. The password is shown once when provisioning finishes, so the safe habit is to store it as a secret before leaving that page.
A different job
Handing databases to your own clients
Shared databases are a separate product. They exist for giving your end-clients isolated, pooled databases on one shared PostgreSQL cluster, rather than for running your own application's data.
Each tenant gets its own database and its own credentials on a cluster you do not have to size, with a connection limit and a storage limit per tenant.