How to choose managed PostgreSQL: Neon, Supabase, Amazon RDS, Cloud SQL or Azure Database for PostgreSQL

Direct answer: choose the operating model and recovery contract before comparing price.

• Trial Neon when you want a PostgreSQL-focused service with usage-based compute, branching, autoscaling and pooled connections.
• Trial Supabase when PostgreSQL is part of a bundled backend platform that may also provide authentication, storage, realtime features, APIs and functions.
• Trial Amazon RDS for PostgreSQL, Google Cloud SQL for PostgreSQL or Azure Database for PostgreSQL Flexible Server when the database must fit a hyperscaler's networking, identity, regions, procurement and operations.

This is not a performance ranking. Nerd Mango did not benchmark these services. A service can be well documented and still be wrong for a particular workload, region, recovery objective or team.

First, name the five exact services

“Managed Postgres” hides different products:

1. Neon Postgres: database-focused platform with separated compute and storage, usage-based plans, branching and autoscaling.
2. Supabase Postgres: a PostgreSQL database at the centre of a wider backend platform.
3. Amazon RDS for PostgreSQL: provisioned AWS-managed PostgreSQL with multiple instance, storage and Multi-AZ choices.
4. Google Cloud SQL for PostgreSQL: Google Cloud-managed PostgreSQL with Enterprise and Enterprise Plus editions.
5. Azure Database for PostgreSQL Flexible Server: Azure-managed PostgreSQL with burstable, general-purpose and memory-optimised options plus optional high availability.

Do not compare a Supabase project fee with one AWS instance line and call the cheaper number a winner. One price may include backend services; another may require separate networking, replicas, backups or support.

The mental model: database, operating envelope and surrounding platform

Think in three layers:

• Database contract: PostgreSQL version, extensions, connection semantics, backups, restore and migration.
• Operating envelope: region, network path, availability design, maintenance, monitoring and support.
• Surrounding platform: authentication, storage, APIs, functions, cloud identity, logging and procurement.

The right service is the one whose whole contract fits the application—not the one with the most attractive starter tier.

Step 1: write a workload contract

Complete this before opening a pricing page.

If a required field is UNKNOWN, the decision is not ready for a “best provider” answer.

Step 2: understand the operating-model differences

Neon: PostgreSQL-focused, elastic operating model

Neon's pricing page retrieved 7 August 2026 lists Free, Launch and Scale plans. Launch uses usage-based compute and storage; the page gives a “typical spend” example but explicitly tells customers to monitor their own usage. It documents plan-specific restore windows, autoscaling and scale-to-zero controls.

Neon offers both direct and pooled connection strings. Its pooler uses PgBouncer in transaction mode. That supports large numbers of client connections, but session-scoped PostgreSQL behaviours such as LISTEN, some temporary-table patterns and session-level advisory locks do not behave like a persistent direct session.

Neon is PostgreSQL, but its compatibility page lists managed-service differences, supported versions and extension constraints. Local filesystem access and privilege requirements can prevent some extensions from being offered.

Trial Neon when: traffic is intermittent or branch-heavy, serverless connections matter, and you are willing to validate transaction-pooler behaviour and the exact region.

Supabase: PostgreSQL inside a backend platform

Supabase states that each project receives a full PostgreSQL database that underpins its Auth, Storage, Realtime and Edge Functions products. This is an important advantage when the application wants that bundle, and an important coupling risk when it does not.

Supabase documents direct, session-pooled and transaction-pooled connection routes. The right endpoint depends on IP version, application lifetime and whether the client requires session state.

Its current pricing page lists a US$25 monthly Pro plan, includes compute credits, and prices compute sizes, egress and optional features separately. The same page says the Free plan has no automatic backups and pauses after inactivity; current figures require a pre-purchase refresh.

Trial Supabase when: the team wants a backend platform rather than only a database and is prepared to map database recovery separately from Storage, Auth and other platform state.

Hyperscaler services: database inside cloud infrastructure

Amazon RDS, Cloud SQL and Azure Flexible Server are not one generic category. They differ in regions, instance families, HA topology, private networking, support and procurement. Their major advantage is often organisational fit: the application, identity, observability and network may already live in the same cloud.

Amazon RDS for PostgreSQL prices instance time, storage, I/O or provisioned IOPS where applicable, backups, transfer and optional support choices. AWS documents Single-AZ and Multi-AZ deployment forms and region-specific feature availability.

Google Cloud SQL pricing varies by edition, region, vCPU, memory, storage, networking and HA choices. Its HA documentation describes regional primary/standby operation; exact behaviour and edition must be checked for the selected configuration.

Azure Flexible Server offers burstable and other compute tiers, optional same-zone or zone-redundant HA, and region-dependent backup redundancy.

Trial a hyperscaler service when: private networking, cloud identity, organisation-wide controls, region catalogue or existing operations outweigh a simpler developer platform.

Decision matrix: what to verify, not who “wins”

Every cell is configuration-dependent. “Supported” does not mean enabled by default or available in every region, plan and PostgreSQL version.

Backups are not a recovery result

A backup claim answers “does the provider retain recovery data?” It does not answer:

• Can your team restore it?
• Does restore create a new server or overwrite the old one?
• Does it include non-database objects?
• How long does the restore take at your data size?
• Are roles, passwords and extensions reproduced?
• Can the backup leave the platform?

Supabase says paid projects receive daily backups with plan-specific retention; its restore documentation warns that physical database backups do not include objects stored through the Storage API and that custom-role passwords are not contained in daily backups.

RDS creates automated backups and supports PITR during the configured retention period.

Azure documents snapshot and transaction-log backups, 7–35 day configured retention, and PITR to a new server. It also says managed backup files cannot simply be exported for use outside Flexible Server; use PostgreSQL tools such as pg_dump and pg_restore for that purpose.

Acceptance test: seed representative data, record the timestamp, delete it, restore to a separate target, validate row counts, roles, extensions, application connectivity and non-database dependencies, then measure elapsed time. A documentation promise is not your measured RTO.

Connection behaviour can disqualify a service design

Serverless applications may create many short-lived connections. A traditional direct PostgreSQL connection per invocation can exhaust available server connections. Poolers reduce connection churn, but transaction pooling changes session semantics.

Before selecting:

1. Identify whether the application uses prepared statements, LISTEN/NOTIFY, session advisory locks, temporary tables or session variables.
2. Test through the exact endpoint—direct, session pool or transaction pool.
3. Set an application-side connection budget.
4. Simulate a connection spike.
5. Verify timeout, queue and retry behaviour.
6. Confirm administrative tools use the correct direct endpoint.

Do not quote a pooler's maximum client count as the number of simultaneous database operations the workload can execute.

Availability: ask what fails and what remains

“High availability” can mean a multi-zone standby, a platform storage architecture, automatic failover or merely a plan-level commitment.

For the proof of concept, test or document:

• compute failure;
• zone failure;
• region failure;
• bad deployment or schema migration;
• accidental deletion;
• exhausted storage or connection limit;
• loss of the application's network path;
• loss of one surrounding dependency such as Auth, Storage, DNS or secrets.

HA does not undo a bad query replicated to every standby. Use point-in-time recovery for logical errors, and test it separately from infrastructure failover.

Extensions and version support

Create an exact extension manifest:

extension name | required version | provider-supported version | privilege needed | restore test | exit target

Supabase publishes a supported extensions list. Neon publishes managed compatibility and extension constraints. Hyperscalers maintain service-specific lists that vary by PostgreSQL major version. Do not assume that “PostgreSQL-compatible” means unrestricted superuser, filesystem or extension access.

Also budget major-version upgrades. AWS, for example, documents Extended Support charges after standard support ends for a PostgreSQL major version.

Regions, networking and compliance

Choose the exact region before price and architecture work. Supabase deploys each project into one primary region and publishes general and exact region options. Neon publishes its active region status endpoints. Hyperscaler features and HA choices vary by region.

Record:

• primary and recovery region;
• public versus private access;
• outbound data path and egress;
• IP version;
• encryption/key requirements;
• identity method;
• audit logging;
• certification or contractual requirement;
• support route during a region incident.

A provider's certification does not automatically make the application compliant. Configuration, contracts and the team's controls still matter.

Monthly-cost worksheet

Use the same workload for every candidate:

Prices are source- and region-specific. There is no single universal monthly-cost winner; compare options only against a frozen workload, region and pricing date.

The two-week proof of concept

Use the same tests for all shortlisted services:

1. Provision the exact region, PostgreSQL version and network path.
2. Install every required extension.
3. Load representative schema and non-sensitive test data.
4. Run the real connection pattern through the intended endpoint.
5. Record normal and peak connection counts.
6. Trigger a controlled application restart and observe reconnection.
7. Restore representative data to a separate target.
8. Test the loss of one surrounding dependency.
9. Export with pg_dump and restore into a neutral PostgreSQL target.
10. Price normal, peak and recovery months from measured usage.
11. Record support response channels and maintenance controls.
12. Stop if any mandatory extension, region, network or recovery requirement fails.

PostgreSQL's pg_dump creates a consistent logical export and is a useful portability tool, but a successful dump alone does not prove that every role, extension, large object or external service will migrate correctly.

Recommendation

Shortlist by operating model:

• database-focused elasticity: Neon;
• integrated backend: Supabase;
• cloud-governed infrastructure: RDS, Cloud SQL or Azure Flexible Server.

Then eliminate any candidate that fails the exact region, extension, connection, recovery, networking or exit test. Compare cost only after the same workload and resilience design is applied to each service.

Sources

• DEV-S01 — Neon pricing
• DEV-S02 — Neon connection pooling
• DEV-S03 — Neon PostgreSQL compatibility
• DEV-S04 — Neon regional status catalogue
• DEV-S05 — Supabase pricing
• DEV-S06 — Supabase database overview
• DEV-S07 — Supabase backups
• DEV-S08 — Supabase PostgreSQL connection methods
• DEV-S09 — Supabase regions
• DEV-S10 — Amazon RDS for PostgreSQL pricing
• DEV-S11 — Amazon RDS automated backups
• DEV-S12 — Amazon RDS features by Region and engine
• DEV-S13 — Cloud SQL pricing
• DEV-S14 — Cloud SQL for PostgreSQL high availability
• DEV-S15 — Azure Database for PostgreSQL pricing
• DEV-S16 — Azure PostgreSQL Flexible Server backup and restore
• DEV-S17 — Azure PostgreSQL Flexible Server high availability
• DEV-S18 — PostgreSQL pg_dump
• DEV-S19 — Supabase Postgres extensions