10 Best Managed Postgres Providers Compared (2026)

Last validated: April 20, 2026. Pricing, SLA, HA, and compatibility claims below were checked against the official docs linked in References.

Note: Railway is included because many teams compare it directly against managed Postgres services, but Railway's own docs describe its database templates as unmanaged by default. [39]

Here at Dreamlit, we've been running on Postgres for a long time and have tried most of the managed providers in this list. Here's what we've learned to help you pick the right one for your workload.

How do the top 10 managed Postgres providers compare?

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 pay out 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 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.

*Google Cloud SQL's shared-core tiers (db-f1-micro, db-g1-small) are not covered by the SLA. For SLA-backed uptime you need dedicated-core Enterprise or Enterprise Plus. [18]

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.

What is 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" support most of Postgres's features, but not all. The devil is in the details. Some providers drop features like triggers, extensions, or stored procedures to get better availability or scalability in return.

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.

Which managed Postgres has automatic failover?

Automatic failover is built into most managed Postgres providers, but the tier you need to be on to get it varies significantly. Here's what each provider offers on its standard paid plan:

The standouts: Supabase requires Enterprise for automatic failover. PlanetScale's $5 single-node tier is non-HA, so you need an HA cluster if you want automatic failover. Railway's default Postgres service is single-node, but Railway now offers an official PostgreSQL HA conversion backed by Patroni. CockroachDB and Aurora DSQL don't have a traditional primary/standby failover at all. They use consensus or active-active replication, so there's no failover event to manage. For most other providers, failover is built in once you choose the HA-capable deployment mode.

Is Supabase or Neon better?

They solve different problems. Supabase and Neon both run native Postgres with a free tier and a great developer experience, but they optimize for different use cases:

• Supabase bundles Postgres with auth, storage, realtime, edge functions, and a dashboard. If you want a full backend instead of just a database, Supabase is usually the faster path. It's also a better fit for teams that want to treat Postgres as the primary source of truth for an app, not just a data store.
• Neon is a serverless Postgres with scale-to-zero compute and per-branch databases. It's the better fit for preview environments, low-traffic apps where you want to pay only for what you use, and workflows where spinning up a throwaway database per git branch matters.

A few concrete tiebreakers:

Both are solid defaults for solo developers and early-stage teams. If you're picking between them for a new app, default to Supabase when you need a backend, Neon when you specifically need serverless 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. [24]

Best for: Solo developers, vibe coders, and early-stage SaaS teams that want Postgres plus auth, storage, and realtime in one product.

Watch out for: Automatic failover is Enterprise-only. For a production workload that can't tolerate minutes of downtime, plan for a Pro + read replicas upgrade path or a different provider. If you're sending app emails off Supabase, see our guide to sending emails from Supabase.

PlanetScale

Overview: A fully managed Postgres platform with unusually strong performance. The $5 entry tier is a single-node Postgres instance; the more production-ready setup starts with HA clusters that add replicas across 3 availability zones. [21] [23] [35]

Availability & Architecture:

• HA clusters run 1 primary + 2 replicas across 3 availability zones in a single region [23]
• The $5 single-node tier is non-HA: one primary, no replicas [35]
• Read-only regions and multi-region deployments are available on supported plans [22] [36]
• Automatic failover on HA clusters typically completes within milliseconds or seconds [23]

Key Differentiators:

• Branching capabilities similar to a git workflow
• Strong HA defaults once you're on an HA cluster
• Locally-attached NVMe (Non-Volatile Memory Express) storage for extremely low latency
• Polished dashboard with query insights that surface slow queries, missing indexes, and schema recommendations before they become incidents

Wire-Protocol Compatibility: PlanetScale Postgres supports the full PostgreSQL feature set, including triggers, stored procedures, and foreign keys. [37]

Best for: Teams that want fast managed Postgres with branching and strong HA defaults, and are willing to pay above the $5 single-node tier for real production availability.

Watch out for: The $5 starting tier is single-node and non-HA. If you need automatic failover, you need an HA cluster, which starts higher. And Neki sharding is still in development, so don't choose PlanetScale today expecting managed Postgres sharding. [35] [50]

Neon

Overview: Serverless Postgres with separated storage and compute layers, enabling fast branching and scale-to-zero compute.

Availability & Architecture:

• Multi-Availability Zone by default for fault tolerance
• Storage is replicated across zones
• Single-region service with same-region read replicas
• Multi-region support on roadmap
• Stateless compute endpoints auto-restart or move to healthy AZs (availability zones) on failures, typically within seconds

Key Differentiators:

• Auto-scales to zero when idle (cost savings for low-traffic apps and preview environments)
• Database branching (a separate Postgres per git branch)
• Usage-based pricing on paid plans (CU-hours + storage), not a flat monthly fee
• Serverless architecture with decoupled storage and compute

Wire-Protocol Compatibility: Neon is Postgres, full feature set. Extensions are whitelisted, otherwise no missing triggers or functions. [25]

Best for: Teams that want per-PR preview databases, hobbyists on the free tier, and workloads with bursty or intermittent traffic where scale-to-zero meaningfully cuts the bill.

Watch out for: The scale-to-zero and storage architecture are newer than most managed Postgres alternatives. Check Neon's status page history before betting production-critical workloads on it. The new usage-based billing model also means your bill scales with compute time, not a flat fee. Model your expected CU-hours before committing.

Railway

Overview: A deploy platform with native Postgres provisioned alongside your app services. Pricing is resource-based on CPU, RAM, storage, and egress, and the developer experience is very Heroku-like. It now offers an official PostgreSQL HA conversion, but Railway's own docs still describe database templates as unmanaged, so you own more of the ops story than on Aurora, Cloud SQL, Supabase, or Neon. For stronger compliance guarantees, Railway points teams to Enterprise or to external managed providers. [32] [38] [39]

Availability & Architecture:

• Default Postgres runs as a single service in one Railway region [34] [41]
• Official PostgreSQL HA converts that service into a Patroni + etcd + HAProxy cluster with automatic leader election and failover [38]
• No documented built-in multi-region database deployment option [39]
• Volume backups can be scheduled daily, weekly, or monthly [42]

What "unmanaged" means on Railway: Railway says its database templates are unmanaged, meaning you are responsible for backups and disaster recovery, performance tuning, security and access control, and ongoing monitoring and maintenance. [39]

Key Differentiators:

• One-click Postgres provisioning; app services auto-wired via DATABASE_URL [34]
• Private networking between app and DB in the same project, with no egress charges for internal traffic [40]
• Resource-based pricing: CPU ~$20/vCPU-month, RAM ~$10/GB-month, volume storage ~$0.15/GB-month [32]
• Config-as-code (TOML/JSON) with PR preview environments [44] [45]

Wire-Protocol Compatibility: Railway's PostgreSQL service runs an SSL-enabled image built from the official Postgres Docker image, so standard Postgres drivers work as expected. Some extensions can be installed directly in Railway's database view, while others require specialized templates such as pgvector. [34] [43]

Best for: Startups and indie teams that want to deploy their app and Postgres on the same platform with a Heroku-like DX (developer experience), private networking, and predictable per-resource pricing, and that are comfortable owning more database operations than they would on a traditional managed Postgres service.

Watch out for: The default Postgres service is still single-node. If you want automatic failover, you need to explicitly convert it to Railway's PostgreSQL HA setup. And even then, Railway does not present its standard database templates as fully managed Postgres. If you need stronger operational ownership or compliance guarantees from Railway itself, the public docs point you toward Enterprise or an external managed provider. [38] [39]

CockroachDB

Overview: Highly available and scalable distributed SQL with Postgres wire-protocol compatibility. More expensive than native Postgres providers at similar scale, in exchange for multi-region writes and stronger consistency guarantees.

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 the CockroachDB engine with some PG feature differences
• Horizontally scalable and globally distributed
• Strict consistency (serializable isolation by default)
• Generous free tier (50M Request Units + 10 GiB storage)
• Advanced multi-region clusters publish a 99.999% SLA

Wire-Protocol Compatibility: PostgreSQL wire protocol on a custom engine. CockroachDB supports much of PostgreSQL syntax, but many PostgreSQL features still differ, and trigger support has notable limitations. [26] [46]

Best for: Teams that specifically need multi-region writes, global low-latency reads, or 99.999% uptime, and that can live without user-installable extensions.

Watch out for: The "Postgres" label is loose here. Existing Postgres apps that rely on extensions, triggers, or specific PL/pgSQL behavior may need rework. Paid tiers are significantly pricier than a single-region Aurora or Cloud SQL instance with similar throughput.

Yugabyte (Aeon)

Overview: Even more expensive than CockroachDB at entry, but highly available and scalable. Branded "Yugabyte Aeon" as the DBaaS.

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 a 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 the PostgreSQL query layer. Unsupported: table inheritance, exclusion constraints, some GiST/GIN indexes, and various extensions (e.g., PostGIS) still pending. [27]

Best for: Enterprises running mission-critical workloads that need geo-distributed strong consistency and are willing to pay for a Yugabyte-managed cluster or self-host the open-source core.

Watch out for: $125/vCPU/month is steep for smaller teams. Feature gaps in the Postgres fork can surface only once you're deep into building. Validate your specific extension and index requirements before committing.

Amazon Aurora (Postgres)

Overview: AWS's cloud-optimized, PostgreSQL-compatible database engine. Overkill for early-stage projects, but a strong default once reliability and scale become production requirements.

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 (Recovery Point Objective) < 1 minute, RTO (Recovery Time Objective) < 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)
• Tight integration with the AWS ecosystem

Wire-Protocol Compatibility: Uses open-source PostgreSQL code and is fully feature-compatible. The only restriction: installing extensions outside the AWS-approved list. [28]

Best for: Production workloads on AWS that need 99.99% uptime, global read replication, and full Postgres feature parity (for teams comfortable with AWS billing complexity).

Watch out for: A db.r6i.large instance runs around $210/month before storage and I/O. For early-stage projects, Supabase, Neon, or Cloud SQL are usually a better starting point.

Aurora Serverless v2

Overview: Serverless version of Aurora. Auto-scales compute capacity in fine-grained ACU increments. On supported Aurora PostgreSQL versions, it can auto-pause all the way down to 0 ACUs when idle. [47] [48]

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 (Aurora Capacity Units)
• Fast failover capabilities
• Can scale to zero ACUs for idle workloads on supported versions (older versions held a 0.5 ACU floor) [47] [48]
• Supports current PostgreSQL versions
• Suitable for unpredictable workloads needing automatic scaling

Wire-Protocol Compatibility: Same Aurora PostgreSQL engine as provisioned Aurora, so the same full compatibility. [28]

Best for: Bursty or unpredictable workloads where provisioned capacity would be over- or under-sized most of the time, and teams that want Aurora's reliability without manually sizing instances.

Watch out for: Per-ACU pricing can exceed a comparably-sized provisioned instance if the workload is consistently busy. Model your typical ACU-hours before switching.

Amazon Aurora DSQL

Overview: Now generally available, with public pricing. The scaling and multi-region active-active design are genuinely interesting, but the Postgres feature set is narrow: closer to a SQL subset than a drop-in Postgres. [49]

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 sub-10ms commit latency
• 99.99% SLA single-region, 99.999% SLA multi-region
• Virtually unlimited scale
• Consumption-based pricing ($8 per million DPUs (Database Processing Units) + $0.33/GB-month storage); free tier includes 100K DPUs and 1 GB/month

Wire-Protocol Compatibility: Connect with any Postgres driver. No user triggers, sequences, PL/pgSQL, extensions, or foreign keys. A subset of SQL only. [29]

Best for: Greenfield workloads that genuinely need multi-region active-active writes and can be built within DSQL's SQL subset from day one.

Watch out for: Don't treat DSQL as a drop-in Postgres. Most Postgres apps can't run on it without significant rework. The DPU billing unit is new. Model spend carefully on realistic traffic.

Google Cloud SQL (Postgres)

Overview: Managed PostgreSQL on Google Cloud. Now split into two editions: Enterprise (99.95% SLA) and Enterprise Plus (99.99% SLA).

Availability & Architecture:

• Single-zone by default
• For the 99.95% SLA, deploy Enterprise in High Availability mode (standby in a different zone)
• Enterprise Plus raises the SLA to 99.99% with faster failover and read pools
• 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 and offers a large catalog of approved extensions (e.g., PostGIS). No feature gaps other than super-user restrictions. [30]

Best for: Teams already on Google Cloud that want native Postgres with HA, and teams evaluating GCP vs. AWS where tight integration with BigQuery, IAM, and Cloud Run matters.

Watch out for: The shared-core tiers (db-f1-micro ~$8/mo, db-g1-small) are not covered by the Cloud SQL SLA. For any workload where uptime matters, size up to dedicated-core Enterprise (from ~$45/mo) or Enterprise Plus.

Which managed Postgres provider should I choose?

Pick the provider whose trade-offs match what you actually care about. Here's the short version by priority:

• Cheapest to start: The free tiers on Supabase, Neon, and CockroachDB cover most hobby projects. Railway also has a constrained free plan if you want app + Postgres on one platform. For the lowest paid tier, PlanetScale single-node and Railway Hobby both start at $5/month, and Google Cloud SQL's shared-core is around $8/month (no SLA). Supabase Pro at $25/month is the cheapest tier with an SLA on native Postgres.
• Best developer experience: Supabase, Neon, PlanetScale, and Railway all have excellent DX in different flavors. Supabase wins if you want backend services bundled in. Neon wins if you want branching and scale-to-zero. PlanetScale wins if you want NVMe-class latency and are willing to pay for an HA cluster. Railway wins if you want your app and Postgres on the same deploy platform.
• Most reliable for production: Amazon Aurora and Google Cloud SQL Enterprise Plus both publish 99.99% SLAs on native Postgres. PlanetScale HA Postgres also publishes 99.99%. For multi-region active-active, Aurora DSQL and CockroachDB Advanced publish 99.999%.
• Most scalable: If you need multi-region writes, you're choosing between CockroachDB, Yugabyte, and Aurora DSQL. Each trades Postgres feature parity for horizontal scale. PlanetScale's Neki is worth watching for managed Postgres sharding, but it's still in development. [50]

In our case at Dreamlit, our web application can tolerate small amounts of downtime, so we optimize for price and developer experience there. Our workflow engine can't tolerate downtime, so it runs on a provider we've tuned for reliability. Most teams make the same split, implicitly or explicitly.

Using managed Postgres with Dreamlit

Whichever provider on this list you pick, Dreamlit connects to your Postgres database and drives email workflows from data changes. No API calls from your app. No cron jobs. Your database is already the source of truth for who signed up, paid, churned, or hit an important milestone. Dreamlit reacts to those changes and sends the email.

If you're on Supabase or any Postgres provider above, you can point Dreamlit at it and describe what you want in plain English. The Workflow Agent generates the trigger logic, the email template, and the copy.

Try Dreamlit free →

References

1. Pricing & Fees | Supabase
2. Service Level Agreement | Supabase
3. Introducing Read Replicas | Supabase
4. Pricing | Neon
5. Neon Service Level Agreement
6. High Availability in Neon Docs
7. CockroachDB Pricing
8. CockroachCloud Technical Service Level Agreement
9. Multi-Active Availability | CockroachDB Docs
10. Pricing | Yugabyte
11. YugabyteDB Aeon Service Level Agreement
12. Raft Consensus Protocol | Yugabyte Docs
13. Amazon Aurora Pricing
14. Amazon Aurora SLA
15. FailoverDBCluster API | Amazon RDS
16. Aurora Serverless v2 Pricing
17. How Aurora Serverless v2 Works
18. Cloud SQL SLA
19. High Availability | Cloud SQL for PostgreSQL
20. Pricing | Cloud SQL for PostgreSQL
21. PlanetScale Postgres Pricing
22. SLA Commitment Improvement | PlanetScale
23. Database Replicas | PlanetScale Postgres Docs
24. Database Overview | Supabase Docs
25. Postgres Compatibility | Neon Docs
26. PostgreSQL Compatibility | CockroachDB Docs
27. Unsupported PostgreSQL Features | YugabyteDB Docs
28. Working with Amazon Aurora PostgreSQL
29. Unsupported PostgreSQL Features in Aurora DSQL
30. Configure PostgreSQL Extensions | Cloud SQL for PostgreSQL
31. Amazon Aurora DSQL Pricing
32. Pricing | Railway Docs
33. Railway Enterprise
34. PostgreSQL | Railway Docs
35. Single Node | PlanetScale Postgres Docs
36. Introducing Global Replica Credentials | PlanetScale
37. Postgres Compatibility | PlanetScale Docs
38. Upgrading PostgreSQL to High Availability | Railway Docs
39. Databases | Railway Docs
40. How Private Networking Works | Railway Docs
41. Regions | Railway Docs
42. Backups | Railway Docs
43. Using the Database View | Railway Docs
44. Using Config as Code | Railway Docs
45. Environments | Railway Docs
46. Triggers | CockroachDB Docs
47. Scaling to Zero ACUs with Automatic Pause and Resume for Aurora Serverless v2
48. Requirements and Limitations for Aurora Serverless v2
49. Amazon Aurora DSQL Is Generally Available
50. Horizontal Sharding for Postgres | PlanetScale Docs

---

Frequently asked questions

What is the best managed Postgres provider in 2026?

It depends on what you're optimizing for. Supabase and Neon are the best fit for solo developers and early-stage teams that want a great DX and a free tier. Amazon Aurora and Google Cloud SQL are the strongest choices for production workloads that need a 99.95%+ SLA on native Postgres. CockroachDB and Yugabyte are built for teams that specifically need multi-region writes and are willing to give up some Postgres features to get it.

What is the cheapest managed Postgres provider?

For hobby and early projects, Supabase, Neon, and CockroachDB all have permanent free tiers that cover small workloads. Railway also has a constrained free plan if you want to run your app and Postgres on the same platform. For the cheapest paid tier, PlanetScale and Railway both start at $5/month (Railway's Hobby plan includes $5 of usage credits on resource-based pricing), and Google Cloud SQL's shared-core db-f1-micro is around $8/month (note: shared-core tiers on Cloud SQL are not covered by Google's SLA). Supabase Pro starts at $25/month. Neon's Launch plan is fully usage-based, typically around $15/month for small workloads.

Is Neon better than Supabase?

They solve different problems. Neon is a serverless Postgres with scale-to-zero compute and per-branch databases, which is great for preview environments and low-traffic apps. Supabase bundles Postgres with auth, storage, and realtime in one product, which is great if you want a full backend rather than just a database.

Which managed Postgres has the best uptime SLA?

CockroachDB, Yugabyte, Amazon Aurora, and PlanetScale all publish a 99.99% uptime SLA on their production tiers. CockroachDB Advanced multi-region, Aurora DSQL multi-region, and PlanetScale multi-region deployments publish 99.999%. Google Cloud SQL is 99.95% on Enterprise dedicated-core and 99.99% on Enterprise Plus. Supabase publishes 99.9% on Enterprise. Neon publishes 99.95% for Business or Scale compute endpoints. SLA numbers are a floor, not a ceiling. Real-world uptime depends on configuration and region.

Does Supabase have automatic failover?

Automatic failover on Supabase is Enterprise-only. Lower tiers run single-instance Postgres in a single availability zone. Read replicas are available on Pro and above but do not automatically promote to primary unless you're on Enterprise.

Is CockroachDB actually Postgres?

No. CockroachDB is a custom distributed SQL engine that speaks the PostgreSQL wire protocol so existing Postgres drivers can connect to it. It supports much of core SQL, but some PostgreSQL features behave differently and trigger support still has limitations. Teams pick it for multi-region consistency, not for full Postgres feature parity.

What's the difference between Aurora and Aurora Serverless v2?

Both use the same Aurora PostgreSQL engine with full Postgres feature parity. Aurora is billed on provisioned instance size. Aurora Serverless v2 auto-scales compute capacity in fine-grained increments (Aurora Capacity Units) based on load. On supported Aurora PostgreSQL versions, Serverless v2 can auto-pause all the way to 0 ACUs when idle. Older versions had a 0.5 ACU floor.

When should I self-host Postgres instead of using a managed provider?

Self-host only if you have dedicated database operations resources. Running Postgres yourself trades a monthly bill for engineering time on backups, patching, replication, failover, and monitoring. For most small and mid-size teams, a managed provider is cheaper once you account for the engineering hours a production-grade setup requires.