Last Updated: May 2025 Here at Dreamlit, we've been using Postgres for a long time. We've tried a lot of different hosted Postgres providers and here's what we've learned so far to help you decide which Postgres provider is right for you. ## Comparison At A Glance **TL;DR:** Here's a table that summarizes the key differences between the managed Postgres providers. For more details on each provider, see the detailed sections below. > SLA (Service Level Agreement) is what the provider promises for uptime. It's not a guarantee, but it's a good indicator of the provider's reliability since they often payout money if they don't meet the SLA (although usually not a lot). > Automatic Failover is the ability for the provider to automatically failover to a new machine in case of a problem. There is failover into a new availability zone (which is at the same data center location) or failover into a new region (which is a different data center location). A failover into a new availability zone is susceptible to the any issues that are affecting an entire region. A failover into a new region is in theory more resilient since it's unlikely for two entire regions to be affected at the same time. | Provider | Key Features | Pricing | SLA | **PG Wire Compat.** | Availability | Automatic Failover | | :-- | :-- | :-- | :-- | :-- | :-- | :-- | | **Supabase** | Integrated auth + storage, Postgres extensions, great DX; read-replica option (Enterprise adds auto-failover) | Free tier; **Pro** from $25 /mo [[1]](#citation-1) | 99.9 % (Enterprise) [[2]](#citation-2) | Native Postgres (≈ 100 %) [[27]](#citation-27) | Multi-AZ ✅; Multi-region ❌ | Enterprise only [[3]](#citation-3) | | **Neon** | Serverless Postgres, autoscaling & scale-to-zero, instant branching, multi-AZ storage | Free tier; **Launch** from $19 /mo [[4]](#citation-4) | 99.95 % (Business) [[5]](#citation-5) | Native Postgres (≈ 100 %) [[28]](#citation-28) | Multi-AZ ✅; Multi-region ❌ | ✅ Built-in HA/auto-restart [[6]](#citation-6) | | **CockroachDB Serverless** | Postgres-API on distributed engine; global scale, zero-downtime schema changes | Free up to 50 M RU + 5 GiB [[7]](#citation-7) | 99.99 % [[8]](#citation-8) | Custom engine; ≈ 85 % (no extensions, triggers = preview) [[29]](#citation-29) | Multi-AZ ✅; Multi-region ✅ | ✅ Consensus replication [[9]](#citation-9) | | **Yugabyte (Managed)** | Distributed SQL with PostgreSQL API; horizontal & geo-scale | vCPU from $125 /mo [[10]](#citation-10) | 99.99 % [[11]](#citation-11) | Postgres fork; ≈ 95 % (some features/extensions unsupported) [[30]](#citation-30) | Multi-AZ ✅; Multi-region ✅ | ✅ Raft consensus [[12]](#citation-12) | | **Azure Cosmos DB for PG** | Citus sharding, horizontal scale, zone-redundant HA | Smallest cluster ≈ $90 /mo [[13]](#citation-13) | 99.95 % [[14]](#citation-14) | Native Postgres + Citus; ≈ 95 % (cross-shard FKs limited) [[31]](#citation-31) | Multi-AZ ✅; Multi-region ✅ | ✅ HA promotes standby [[15]](#citation-15) | | **Amazon Aurora (Postgres)** | AWS-optimised Postgres; 6 × replicated storage; Global DB | Usage-based [[16]](#citation-16) | 99.99 % [[17]](#citation-17) | Native Postgres (≈ 100 %) [[32]](#citation-32) | Multi-AZ ✅; Multi-region ✅ | ✅ < 1 min failover [[18]](#citation-18) | | **Aurora Serverless v2** | Fine-grained autoscaling; fast failover | $0.12 / ACU-hr [[19]](#citation-19) | 99.99 % | Native Postgres (≈ 100 %) [[32]](#citation-32) | Multi-AZ ✅; Multi-region ❌ | ✅ Same as standard Aurora [[20]](#citation-20) | | **Amazon Aurora DSQL** | *Preview*: serverless distributed SQL; multi-region active-active | Free during preview [[32]](#citation-32) | Preview (no SLA) | Custom distributed engine; core SQL only (no triggers/extensions) [[33]](#citation-33) | Multi-AZ ✅; Multi-region ✅ | Active-active (no traditional failover) | | **Google Cloud SQL (Postgres)** | Fully managed Postgres; easy HA, automated backups | Shared-core ≈ $11 /mo [[23]](#citation-23) | 99.95 % [[21]](#citation-21) | Native Postgres (≈ 100 %) [[34]](#citation-34) | Multi-AZ ✅; Multi-region ❌ | ✅ Automatic failover [[22]](#citation-22) | | **PlanetScale** (MySQL) | Vitess-based DBaaS, branching; MySQL only | **Scaler** $29 /mo [[24]](#citation-24) | 99.99 % / 99.999 % [[25]](#citation-25) | *MySQL (not Postgres)* | Multi-AZ ✅; Multi-region ✅ | ✅ Vitess rapid failover [[26]](#citation-26) | For more detailed information about each provider, continue reading the sections below. ## What is a hosted Postgres provider? A hosted Postgres provider is a service that allows you to run Postgres in the cloud. It's a managed service that takes care of the underlying infrastructure, so you can focus on building your application. ### What are the benefits? You don't have to worry about: - The underlying infrastructure - Scaling the database - Backups - Patching the database - Disaster recovery - Monitoring - Alerting ### What about self-hosting? You can run Postgres on your own infrastructure. And there's a whole spectrum of options. 1. Self-host Postgres on the same machine as your application. 2. Self-host Postgres on a single machine in a data center like AWS EC2 or Digital Ocean Droplet. 3. Self-host Postgres on a multi-machine cluster in a data center. All these have trade-offs, but for this post we're going to focus on the hosted Postgres providers with the belief that **managed Postgres gives engineers and builders in general the most leverage.** ## Postgres Wire-Protocol Compatibility The PostgreSQL wire protocol is the on-the-wire language that every Postgres client (psql, JDBC, Psycopg, etc.) speaks. When a service claims "Postgres-compatible," it usually means: 1. **Protocol level** – you can connect with standard Postgres drivers. 2. **SQL dialect** – basic DDL/DML/ACID semantics match. 3. **Feature depth** – advanced bits (extensions, triggers, stored procs, foreign keys, etc.) also work. Providers that are "Postgres-compatible" will have a good amount of the features of Postgres. But the devil is in the details. Many of the Postgres providers do not support all the features of Postgres like triggers, extensions, stored procedures, etc. (usually to better support something else like better availability or scalability). It would be wise to double check that the provider you're considering supports the features you need. **Just because they say it's Postgres, doesn't mean it's 100% Postgres.** ## Provider Details ### Supabase **Overview:** Strong emphasis on developer experience. Cheap to start and easy to use. **Availability & Architecture:** - Single-region deployments (you choose your region on AWS infrastructure) - No built-in multi-region clustering - Read replicas available on higher tiers for horizontal scaling - Enterprise tier includes automatic failover by promoting read replicas if the primary fails **Key Differentiators:** - Integrated auth, storage, and other backend services - Great developer experience with simple APIs - Strong open-source commitment - Branching and other developer features in preview - Well-suited for small to medium applications **Wire-Protocol Compatibility:** Runs **native PostgreSQL** — all features (triggers, extensions, PL/pgSQL, foreign keys) work out of the box. [[27]](#citation-27) ### Neon **Overview:** Serverless Postgres with separated storage and compute layers for cool branching tech. Questionable uptime in practice. Recently acquired by Databricks. **Availability & Architecture:** - Multi-Availability Zone by default for fault tolerance - Storage is replicated across zones - Single-region service with same-region read replicas in beta - Multi-region support on roadmap - Stateless compute endpoints auto-restart or move to healthy AZs on failures, typically within seconds **Key Differentiators:** - Auto-scales to zero when idle (cost savings) - Database branching support (create a database per git branch) - Relatively new platform with free tier for development/testing - Serverless architecture with decoupled storage and compute **Wire-Protocol Compatibility:** Neon **is Postgres**; full feature set. Extensions are whitelisted, otherwise no missing triggers/functions. [[28]](#citation-28) ### CockroachDB Serverless **Overview:** Expensive, but highly available and scalable. Postgres-compatibile enough depending on your needs. **Availability & Architecture:** - Multi-node distributed SQL cluster using Raft consensus across 3+ nodes - Data replicated across Availability Zones for node/AZ failure resilience - Multi-region clusters supported (can span select cloud regions) - Built-in consensus replication without a single primary node - If a node fails, another takes over leadership automatically **Key Differentiators:** - Postgres-compatible wire protocol, but NOT actual Postgres under the hood - Uses CockroachDB engine with some PG feature differences - Highly scalable, globally-distributed database - Strict consistency (serializable isolation by default) - Generous free tier (50M Request Units + 10 GiB storage) **Wire-Protocol Compatibility:** PostgreSQL wire protocol on a **custom engine**. Missing pieces: no user-installable extensions; triggers & stored procs still **preview**. [[29]](#citation-29) ### Yugabyte (Managed) **Overview:** Even more expensive than CockroachDB, but highly availble and scalable. **Availability & Architecture:** - Deployed as a cluster of nodes (minimum 3 nodes for high availability) - Standard tier provides zone-level resilience (multi-AZ cluster) - Higher tiers support multi-region clustering for regional fault tolerance - Built-in Raft consensus for leader election and self-healing - Automatically fails over on node/zone failures **Key Differentiators:** - Distributed SQL database with PostgreSQL API (YSQL) - Also offers Cassandra-like API (YCQL) - Open-source core with commercial managed offering - Horizontally scalable and geo-distributed - Ideal for mission-critical applications requiring strong consistency across regions **Wire-Protocol Compatibility:** Fork of PostgreSQL query layer. Unsupported: table inheritance, exclusion constraints, some GiST/GIN indexes, and various extensions (e.g., PostGIS) still pending. [[30]](#citation-30) ### Azure Cosmos DB for PostgreSQL **Overview:** Azure's scale-out Postgres solution powered by open-source Citus sharding. **Availability & Architecture:** - Can start on one node and scale to a multi-node cluster - High-availability option adds a standby in another AZ - Supports multi-region read replicas for low-latency global reads and disaster recovery - When HA is enabled, automatic failover to standby node on primary failure **Key Differentiators:** - Managed Hyperscale (Citus) Postgres on Azure - Enables horizontal scaling for multi-tenant or sharded applications - Different from single-server Azure Database for PostgreSQL - Targeted at cloud-native apps needing distributed Postgres - Familiar PostgreSQL syntax with scale-out capabilities **Wire-Protocol Compatibility:** Native PostgreSQL with Citus. Limitation: **cross-shard foreign keys** (and some AFTER-ROW triggers) not supported. [[31]](#citation-31) ### Amazon Aurora (Postgres) **Overview:** AWS's cloud-optimized, PostgreSQL-compatible database engine. Might be over-kill in the early days. **Availability & Architecture:** - Multi-AZ architecture with storage replicated 6x across 3 AZs - Supports up to 15 Aurora Replicas across AZs for read scaling and high availability - "Aurora Global Database" option for cross-region replication - Cross-region failover with RPO < 1 minute, RTO < 1 minute - Automatic failover to an Aurora Replica completes within ~30 seconds with zero data loss **Key Differentiators:** - Proprietary AWS implementation optimized for cloud - Improved performance and features (parallel query, Global DB) - Maintains PostgreSQL compatibility - Fully managed on AWS (not open source) - Seamless integration with AWS ecosystem **Wire-Protocol Compatibility:** Uses open-source PostgreSQL code; full feature parity. Only restriction: installing extensions outside AWS-approved list. [[32]](#citation-32) ### Aurora Serverless v2 **Overview:** Serverless version of Aurora. Mixed reviews based on reddit in terms of performance and reliability. Doesn't scale all the way down to zero. **Availability & Architecture:** - Always runs in multi-AZ configuration with shared storage across AZs - Supports multiple readers and all standard Aurora features - Clusters can have read replicas for quicker failover and read scaling - Instantly scales compute capacity up/down based on load without downtime - Behaves like standard Aurora for HA with ~30s failover time **Key Differentiators:** - On-demand auto-scaling with fine-grained adjustments - Fast failover capabilities - Does NOT pause to $0 (0.5 ACU minimum running) - Supports newer PostgreSQL versions - Suitable for unpredictable workloads needing automatic scaling **Wire-Protocol Compatibility:** Same Aurora PostgreSQL engine ⇒ same full compatibility. [[32]](#citation-32) ### Amazon Aurora DSQL **Overview:** The scaling and availability look super interesting, but the feature set is severely limited. Barely even looks like Postgres in its current state. **Availability & Architecture:** - Disaggregated compute / log / storage layers - Synchronous replication across 3 AZs; optional multi-Region quorum - Active-active design eliminates failover outages **Key Differentiators:** - Writes in any Region with <10 ms commit latency and **99.999 %** design availability - Virtually unlimited scale; consumption-based pricing (after GA) **Wire-Protocol Compatibility:** Connect with any Postgres driver. ✘ Currently **no user triggers, sequences, PL/pgSQL, extensions, or foreign keys** (subset of SQL only). [[33]](#citation-33) ### Google Cloud SQL (Postgres) **Overview:** Managed PostgreSQL service but on Google Cloud. **Availability & Architecture:** - Single-zone by default - For 99.95% SLA, deploy in High Availability mode (standby in different zone) - Supports cross-region read replicas for read scaling and disaster recovery - Primary is single-region (no multi-region writes) - Automatic failover to standby when HA is enabled **Key Differentiators:** - Fully managed PostgreSQL on Google Cloud - Automated backups, updates, and vertical scaling - No built-in sharding (one primary node plus optional replicas) - Suitable for moderate-scale applications - For higher scalability needs, Google recommends Cloud Spanner or AlloyDB **Wire-Protocol Compatibility:** Runs unmodified PostgreSQL; large catalog of approved extensions (e.g., PostGIS). No feature gaps other than super-user restrictions. [[34]](#citation-34) ### PlanetScale **Overview:** A popular MySQL-based serverless database platform (included for comparison). No longer has a free tier. Scaling and availability look good. **Availability & Architecture:** - Single-region by default with data replicated across multiple AZs - Multi-region deployment available for Enterprise plans - Auto-failover to another AZ on zone failures - Multi-region setups can fail over across regions - Built on Vitess for automatic failover (rapidly promotes replica to primary) **Key Differentiators:** - MySQL-only service (not Postgres) - Uses Vitess clustering technology - Serverless-like MySQL with non-blocking schema changes - Branching capabilities similar to git workflow - Enterprise plans offer strong SLAs and multi-region capabilities ## Thinking about the different trade-offs What do you care most about? Price? Developer experience? Reliability and uptime? These will heavily influence your decision. Solopreneurs and small teams will care about price and developer experience. And realistically speaking a smaller application can tolerate small amounts of downtime (a few minutes here and there). If you're an infrastructure provider (a.k.a. other companies rely on you for your uptime), you'll need to focus on reliability and uptime. In our case at Dreamlit, our web application can tolerate some downtime whereas our Workflow engine cannot tolerate any downtime. So for our web application, we can focus on price and developer experience. But for our Workflow engine, we need to focus on reliability and uptime. Sources: 1. [Pricing & Fees | Supabase](https://supabase.com/pricing) 2. [Service Level Agreement | Supabase](https://supabase.com/sla) 3. [Introducing Read Replicas | Supabase Blog](https://supabase.com/blog/introducing-read-replicas) 4. [Pricing — Neon](https://neon.tech/pricing) 5. [Neon Business SLA](https://neon.tech/neon-business-sla) 6. [High Availability in Neon Docs](https://neon.tech/docs/introduction/high-availability) 7. [CockroachDB Pricing](https://www.cockroachlabs.com/pricing/) 8. [CockroachDB Serverless Free Tier (99.99 % uptime)](https://www.cockroachlabs.com/blog/serverless-free/) 9. [Multi-Active Availability | CockroachDB Docs](https://www.cockroachlabs.com/docs/stable/multi-active-availability) 10. [Pricing | Yugabyte](https://www.yugabyte.com/pricing/) 11. [YugabyteDB Aeon SLA (99.99 %)](https://www.yugabyte.com/yugabytedb-aeon-service-level-agreement/) 12. [Raft Consensus Protocol | Yugabyte Docs](https://docs.yugabyte.com/preview/architecture/docdb-replication/raft/) 13. [Pricing | Azure Cosmos DB for PostgreSQL](https://azure.microsoft.com/pricing/details/cosmos-db/postgresql/) 14. [High Availability Concepts | Azure Cosmos DB for PostgreSQL](https://learn.microsoft.com/azure/cosmos-db/postgresql/concepts-high-availability) 15. [Configure HA | Azure Cosmos DB for PostgreSQL](https://learn.microsoft.com/azure/cosmos-db/postgresql/howto-high-availability) 16. [Amazon Aurora Pricing](https://aws.amazon.com/rds/aurora/pricing/) 17. [Amazon Aurora SLA (99.99 %)](https://aws.amazon.com/rds/aurora/sla/) 18. [FailoverDBCluster API (≤ 35 s failover)](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) 19. [Aurora Serverless v2 Pricing](https://aws.amazon.com/rds/aurora/pricing/) 20. [How Aurora Serverless v2 Works (automatic failover)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html) 21. [Cloud SQL SLA (99.95 % HA)](https://cloud.google.com/sql/sla) 22. [High Availability | Cloud SQL (Postgres)](https://cloud.google.com/sql/docs/postgres/high-availability) 23. [Pricing | Cloud SQL (Postgres)](https://cloud.google.com/sql/docs/postgres/pricing) 24. [Pricing | PlanetScale](https://planetscale.com/pricing) 25. [SLA Commitment Improvement (99.99 % / 99.999 %)](https://planetscale.com/changelog/sla) 26. [Database Replicas (auto-failover) | PlanetScale Docs](https://planetscale.com/docs/concepts/replicas) 27. [Database Overview – Supabase Docs](https://supabase.com/docs/guides/database/overview) 28. [Postgres Compatibility – Neon Docs](https://neon.tech/docs/reference/compatibility) 29. [Triggers (Preview) – CockroachDB Docs](https://www.cockroachlabs.com/docs/stable/triggers) 30. [Unsupported PostgreSQL Features – YugabyteDB Docs](https://docs.yugabyte.com/preview/develop/postgresql-compatibility/) 31. [Modify Distributed Tables (Foreign-Key limits) – Azure Cosmos DB for PostgreSQL](https://learn.microsoft.com/azure/cosmos-db/postgresql/howto-modify-distributed-tables) 32. [Working with Amazon Aurora PostgreSQL – AWS Docs](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) 33. [Unsupported PostgreSQL Features in Aurora DSQL (Preview)](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html) 34. [Configure PostgreSQL Extensions – Cloud SQL for PostgreSQL](https://cloud.google.com/sql/docs/postgres/extensions)

Latest updates and newsfrom Dreamlit

Latest

Latest updates and news
from Dreamlit