Database hosting services, compared
Each provider is profiled from its own documentation, with the source recorded against every figure. Backup retention, point-in-time recovery and read replicas are compared separately on the reliability page.
Managed databases
| Provider | Connection limit | When idle | Database branching |
|---|---|---|---|
| Aiven | Set per plan, not by a formula: 100 on the entry paid plan (Startup-4), rising to 200, 400, 800 and 1000 as the plan grows, with 25 on Hobbyist, 20 on Free and 15 on Developer. Aiven states plainly that it does not apply a per-GiB formula, and that some of the allowance is used by Aiven itself to manage the service. | Not documented | Limited — a full copy from the latest backup, not copy-on-write |
| Amazon Aurora | Derived from memory, not set per plan. On Aurora serverless the default follows the maximum ACU setting — 90 connections on MySQL and 189 on PostgreSQL at 1 ACU, 135/823 at 4 ACUs, 1,000/1,669 at 8 ACUs — and a minimum capacity of 0 or 0.5 ACUs caps PostgreSQL at 2,000. | Pauses only in serverless mode with minimum capacity set to zero ACUs: the instance auto-pauses after an idle interval you choose — 300 seconds (five minutes) by default and at minimum, up to 86,400 seconds (one day) — and resumes automatically when a connection request arrives. | Limited — clones, not a branch workflow |
| Amazon RDS | Not a fixed number: RDS for PostgreSQL sets max_connections by formula from the instance's memory — LEAST({DBInstanceClassMemory/9531392}, 5000) — so a bigger instance class gets more connections and the ceiling is 5,000 however large it is. The parameter can be set by hand anywhere from 6 to 262,143, which is a limit on what you may configure rather than what an instance will serve. Other engines use different divisors: MySQL is memory/12582880 with no cap. | A DB instance can be stopped for at most 7 consecutive days, with no instance-hour charges while stopped but provisioned storage and backups still billed; RDS then starts it automatically. | Not documented |
| Crunchy Bridge | Not documented | Not documented | Limited — a new cluster restored from backup, to any minute in 10 days |
| Firebase | Not documented | Not documented | Not documented |
| Neo4j | Not documented | Not documented | Not documented |
| Neon | Scales with compute size: 104 direct connections at 0.25 CU (1 GB RAM), 419 at 1 CU, 2517 at 6 CU; up to 10,000 through the pooler | Compute suspends after 5 minutes idle on Free and Launch, and can be disabled on Launch; configurable from 1 minute to always-on on Scale. The database is not deleted or paused — the next query restarts the compute. | Supported |
| Nile | 10,000 connections on Pro, with connection pooling included. | No cold start on Pro — Nile lists it as a plan feature rather than a behaviour to configure. | Not supported — Pricing marks Branching 'Coming soon': one branch Free, 50 Pro, unlimited Scale. |
| PlanetScale | Not documented | Not documented | Supported |
| Prisma Postgres | 100 pooled connections on Starter and 10 direct; 10 pooled on Free, 500 on Pro and 1,000 on Business. | Scales to zero when idle, and Prisma states an idle app costs nothing. | Not documented |
| ScaleGrid | No platform cap published: max_connections (maximum permitted simultaneous client connections) is listed as a customer-editable MySQL server parameter in the ScaleGrid console. | Manual pause/resume on Bring Your Own Cloud clusters: a paused cluster's nodes are stopped and its cloud VM costs stop, but ScaleGrid management costs continue and the data is unreachable until resumed. Only standard clusters using persistent storage; high-performance local-SSD clusters cannot be paused. | Limited — Clone copies a backup's config and contents into a new, separately billed cluster, not an in-place branch. |
| Supabase | 60 direct and 200 pooled connections on the Micro instance included with Pro; both scale with instance size | Free projects are paused after one week of inactivity and must be restored manually; paid projects are not paused | Supported |
| TigerData | max_connections settable 25-500 on services from 0.5 CPU / 2 GiB to 4 CPU / 16 GiB, and 25-2000 from 8 CPU / 32 GiB up; fixed at 25 on shared CPU | Billed while running: all active standard services are charged even when not in use, and unused ones must be paused or deleted manually | Supported — Service forks, created at current state, last snapshot, or a timestamp in the plan recovery window. |
| Turso | Not documented | Databases are archived after 10 days of inactivity on the free plan; an unarchive call through the CLI or Platform API brings the group back. Turso publishes no archival window for paid plans. | Supported |
Which to consider
Teams who want more than one open-source data service from one vendor and one bill — Postgres beside Kafka, ClickHouse or OpenSearch — with the availability tier chosen per service rather than fixed.
Teams on AWS who want a Postgres or MySQL cluster that can throw off a copy-on-write clone of production in minutes, keep up to fifteen readers behind it, and pause to nothing between bursts in serverless mode.
Teams already inside AWS, where the database sitting in the same VPC as everything else is worth more than any single feature on this page. Six engines, up to 35 days of point-in-time recovery, and read replicas you create and delete yourself.
Anyone who wants Postgres and nothing else, from people who work on Postgres. Ten days of per-minute recovery is included in the price of every cluster rather than sold as a tier, and replicas can sit in another region or another cloud.
Apps that want a NoSQL document database with no plan fee: Firestore's no-cost quota covers 1 GiB stored and 50,000 reads a day, and past it you pay per operation — $0.03 per 100,000 reads at the default Iowa rate — with 99.99% to 99.999% uptime by location.
Teams whose data is naturally relationships-first — recommendation engines, fraud detection, knowledge graphs — where the query itself is a graph traversal Cypher expresses directly and a relational join chain would not.
Workloads that are idle most of the time, and teams who want a real database per pull request. Compute suspends after five minutes and storage is billed separately, so a staging branch costs almost nothing while nobody is using it.
Multi-tenant SaaS where every customer wants isolation — Nile makes a database per tenant the default shape rather than something you build on top of Postgres.
Production workloads that want replicas across availability zones as the default shape rather than an upgrade, and teams who need MySQL-compatible sharding that the Postgres-only services do not offer.
Prisma ORM users who want the database and the client from one vendor, with a pooled connection limit stated per plan rather than left to be discovered.
Teams that already have a favored database engine and cloud provider but want someone else operating it — the BYOC model bills infrastructure at cost and adds management on top, worth it if the operational burden is the actual problem.
Teams who want Postgres plus auth, storage and generated APIs from one vendor on a fixed monthly bill, and who would otherwise assemble those pieces themselves.
Time-series and analytics workloads that want to stay in Postgres — TimescaleDB's compression is the reason the storage line is affordable at volume.
Applications that want a database per tenant or per user — 100 databases on the free plan and unlimited above it make that a shape you can actually build.
Managed databases in the news
- Databricks to Acquire Neon in $1 Billion Deal to Boost AI-Driven Databases - TechRepublic
- Lakebase Search: State-of-the-art full text and vector search for Postgres - Databricks
- Retool scales smarter with Lakebase - Databricks
- AWS RDS vs Azure Database vs Google Cloud SQL: 25% Price Gap [2026] - tech-insider.org
Comments are hosted by EchoThread, which sets cookies and offers social sign-in. Like the analytics on this site, it does not load until you accept — see the privacy page.