Managed databases: the agent answers

I’d use **Neon**, assuming this is a conventional application workload and its supported regions, extensions, compliance, and availability commitments meet your requirements.

It matches your priorities unusually well:

- **Preview environments:** Neon’s copy-on-write branches are the strongest fit. A CI job can create a production-like database branch for each pull request, run migrations, inject its connection string into the preview deployment, and delete it afterward. Branches can also be schema-only when production data must not enter previews. [Neon branching documentation](https://neon.com/docs/guides/branching-intro)
- **Serverless connections:** Use Neon’s pooled endpoint for normal application traffic. Its managed PgBouncer supports large numbers of mostly short-lived connections; retain the direct endpoint for migrations and administrative work. [Neon connection-pooling documentation](https://neon.com/docs/connect/connection-pooling)
- **Recovery:** Neon retains database history and supports point-in-time restoration within a configurable restore window. Be deliberate here: paid projects now default to only a one-day window, so set the production window to your actual recovery requirement and monitor its cost. [Neon restore-window documentation](https://neon.com/docs/manage/projects)
- **Operations:** It manages minor-version updates and security patches, and separates compute from storage, allowing autoscaling and scale-to-zero for non-production branches.

### What else I considered

| Provider | Why consider it | Why it isn’t my first choice here |
|---|---|---|
| **Supabase** | Managed Postgres, backups/PITR, serverless-friendly Supavisor pooling, and GitHub preview branches | Best when you also want its Auth, Storage, Realtime, and API platform. Its preview branches are separate data-less environments seeded through migrations, rather than Neon-style production-data branches. [Branching](https://supabase.com/docs/guides/deployment/branching), [connections](https://supabase.com/docs/guides/database/connecting-to-postgres) |
| **AWS Aurora PostgreSQL Serverless v2** | Mature AWS networking, IAM, backups, replicas, HA, compliance, and RDS Proxy | Strong production infrastructure, but considerably more AWS machinery and no comparably simple database-per-preview branching workflow. “Serverless” also does not remove the need to design VPC, proxy, scaling, and cost controls. [AWS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) |
| **Crunchy Bridge** | Excellent PostgreSQL focus, managed PgBouncer, automatic backups, PITR forks, downloadable backups on some clouds | A very credible choice when PostgreSQL fidelity, portability, or support matters more than ephemeral previews. Its forks provision full clusters and are billed accordingly, so they are less natural for every-PR environments. [Restore documentation](https://docs.crunchybridge.com/how-to/restore-backups) |
| **Cloud-provider managed Postgres** | Conservative default, private networking, integrated compliance and procurement | Reliable, but connection proxies and preview database cloning usually require more infrastructure and automation. |

Before committing, I’d run a short proof of concept covering your largest database, required extensions, migration duration, sustained production workload, failover expectations, and preview-branch cleanup. I would also keep nightly logical exports in separate object storage: provider PITR is the primary recovery mechanism, but it shouldn’t be your only portable escape route.

I’d use **Neon**, assuming your workload fits its supported Postgres extensions and available regions.

It aligns unusually well with your requirements:

- **Serverless-friendly connections:** built-in PgBouncer transaction pooling supports up to 10,000 concurrent connections. Use the pooled URL for application traffic and the direct URL for migrations, `pg_dump`, advisory locks, and other session-dependent work. [Neon connection pooling](https://neon.com/docs/connect/connection-pooling)
- **Preview environments:** copy-on-write database branches are fast, isolated, and automatable through GitHub Actions or deployment integrations. Branch expiration can clean up previews automatically. [Neon branching](https://neon.com/docs/guides/branching-intro)
- **Recovery:** point-in-time restore and branches from historical states are built in. The current Launch plan supports up to seven days of restore history; Scale supports up to 30 days. Retention must be configured—it defaults to one day on paid projects. [Neon pricing](https://neon.com/pricing)
- **Maintenance:** Neon applies minor-version upgrades and security patches automatically, with configurable maintenance windows on paid plans. [Neon project management](https://neon.com/docs/manage/projects)

### What else I considered

| Provider | Where it wins | Why it isn’t my first choice here |
|---|---|---|
| **Supabase** | Excellent if you also want auth, storage, realtime APIs, and row-level-security-driven frontend access. It has Supavisor transaction pooling and PR preview branches. | More of an application backend platform than a focused database service. Preview branches create whole Supabase environments, and PITR is a relatively expensive add-on requiring larger compute. [Connections](https://supabase.com/docs/guides/database/connecting-to-postgres), [branching](https://supabase.com/docs/guides/deployment/branching), [backups](https://supabase.com/docs/guides/platform/backups) |
| **Aurora PostgreSQL Serverless v2** | Best choice if you are deeply committed to AWS and need mature IAM, VPC, compliance, replicas, and operational controls. RDS Proxy handles connection surges. | Preview databases require Aurora clones and additional infrastructure orchestration; it is substantially more complex than Neon branching. “Serverless” also doesn’t make the operational surface disappear. [RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html), [Aurora cloning](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.Cross-VPC.html) |
| **Cloud SQL for PostgreSQL** | Conventional, dependable managed Postgres with strong backup/DR options and GCP integration. | Managed connection pooling requires Enterprise Plus, while database-per-PR workflows are comparatively cumbersome. [Pooling](https://docs.cloud.google.com/sql/docs/postgres/managed-connection-pooling), [backups](https://docs.cloud.google.com/sql/docs/postgres/backup-recovery/backups) |
| **Plain RDS PostgreSQL / Crunchy Bridge** | Familiar, conservative managed Postgres with fewer architectural surprises. | Good “managed VM replacement,” but weaker against your branching and serverless-specific requirements. |

### Caveats before committing

Neon’s restore history should not be your only disaster-recovery mechanism. It protects well against logical mistakes, but it lives inside the same provider and account boundary. I would also schedule encrypted `pg_dump` exports into a separately controlled object-storage account and regularly test restoring them.

Before migration, verify:

- Required extensions and Postgres version
- Database size, write rate, and acceptable restore window
- Region latency and data-residency requirements
- Any session features incompatible with transaction pooling
- Long-running jobs, logical replication, and connection-heavy tooling
- Peak compute requirements and whether scale-to-zero cold starts are acceptable

My deployment pattern would be **Neon Launch for production**, pooled connections for serverless requests, direct connections for migrations/workers, one database branch per pull request, automatic branch expiry, seven-day PITR, plus independent logical backups. Move to Scale if you need a 30-day restore window, private networking, SLA, or stronger compliance controls.

I’d use **Neon**, assuming your workload fits its supported Postgres extensions and regions.

It matches your requirements unusually well:

- Managed Postgres with automatic patching and point-in-time recovery. Neon retains database history through a configurable restore window and supports instant restores and snapshots. Check the retention included in your chosen plan—paid projects currently default to a one-day restore window, which you’ll probably want to extend. [Neon backup and restore](https://neon.com/docs/manage/projects)
- A pooled PgBouncer endpoint designed for bursty/serverless workloads, supporting up to 10,000 client connections. Keep a separate direct connection for migrations, `pg_dump`, and session-dependent operations. [Neon connection pooling](https://neon.com/docs/connect/connection-pooling)
- Copy-on-write database branches containing both schema and data, created through its API, CLI, GitHub Actions, or Vercel integration. This is the cleanest preview-environment story among the options I considered. [Neon branching](https://neon.com/docs/guides/branching-intro), [preview workflow](https://neon.com/docs/get-started-with-neon/workflow-primer)

The connection setup I’d standardize on is:

- `DATABASE_URL`: pooled endpoint for application traffic.
- `DIRECT_DATABASE_URL`: direct endpoint used only by migrations and administrative tooling.
- One ephemeral branch per pull request, with automatic deletion when the PR closes.
- A separate non-production parent branch containing sanitized representative data, rather than branching previews directly from production.

That last point matters: Neon branches can inherit production data. Copy-on-write makes them cheap and fast, but it does not make sensitive data harmless.

What else I considered:

| Provider | When I’d choose it instead | Main tradeoff |
|---|---|---|
| **Supabase** | You also want Auth, Storage, Realtime, APIs, or a broader backend platform | Good serverless pooling and PR branches, but new branches are data-less and reconstructed from migrations/seeds rather than being production-data clones. [Branching](https://supabase.com/docs/guides/deployment/branching), [connections](https://supabase.com/docs/guides/database/connecting-to-postgres) |
| **Aurora PostgreSQL Serverless v2** | You are deeply invested in AWS, need private networking/IAM integration, mature DR controls, or stronger enterprise procurement alignment | Excellent backups and HA; RDS Proxy handles connection bursts, but database cloning is heavier and preview branching requires more automation and cost management. [Aurora Serverless](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html), [backups](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html) |
| **Cloud SQL for PostgreSQL** | Your applications already run on GCP and conventional managed Postgres is more important than branching | Strong backups and managed pooling, but no first-class copy-on-write PR branching workflow. [Backups](https://docs.cloud.google.com/sql/docs/postgres/backup-recovery/backups), [managed pooling](https://docs.cloud.google.com/sql/docs/postgres/managed-connection-pooling) |
| **Traditional managed Postgres such as Crunchy Bridge** | You prefer a conservative, operationally conventional Postgres service with strong DBA support | A good database service, but branching and scale-to-zero serverless ergonomics are not the central product model. |

Before committing, I’d run a short migration rehearsal covering:

- Installed extensions, logical replication, scheduled jobs, superuser-dependent operations, and parameter differences.
- Peak query throughput and connection concurrency—not merely database size.
- Cold-start tolerance if compute can suspend.
- Restore testing, not just confirmation that backups exist.
- Region, SLA, support tier, compliance, private networking, and acceptable recovery windows.
- A `pg_dump`/restore or replication-based cutover rehearsal, followed by validation of row counts, sequences, permissions, and application latency.

So the short version is: **Neon is my default for this exact brief; Aurora is my enterprise/AWS fallback; Supabase wins if you want the rest of its backend platform as well as Postgres.**

I’d use **Neon**, assuming your workload is ordinary application Postgres and its supported extensions and regions meet your requirements.

It most directly matches what you asked for:

- Managed Postgres with automated patching and a configurable point-in-time restore window. Paid plans currently support up to 7 or 30 days depending on tier. I would still keep periodic independent logical exports for disaster recovery and vendor exit; externally exported backups are not yet Neon’s strongest area. [Neon restore documentation](https://neon.com/docs/manage/projects)
- A pooled PgBouncer endpoint designed for bursty/serverless workloads, supporting up to 10,000 client connections. For JavaScript runtimes, Neon also offers an HTTP/WebSocket driver. [Connection pooling](https://neon.com/docs/connect/connection-pooling), [serverless driver](https://neon.com/docs/serverless/serverless-driver)
- Fast copy-on-write branches containing the parent’s schema and data, each with its own connection string. They can be created and deleted through the API, CLI, GitHub Actions, or a Vercel integration. Schema-only branches are available when production data should not enter preview environments. [Branching workflow](https://neon.com/docs/get-started-with-neon/workflow-primer)

The important qualification is that “managed Postgres” isn’t identical to VM Postgres. Neon does not provide host access or a true Postgres superuser, supports a defined extension set, and limits instance-level configuration. Audit your extensions, parameter overrides, tablespaces, logical replication, and operational scripts before committing. [Compatibility details](https://neon.com/docs/reference/compatibility)

What else I’d consider:

| Provider | When I’d choose it instead | Main drawback here |
|---|---|---|
| **Supabase** | You also want integrated auth, storage, realtime, edge functions, or a database API | Its preview branches are separate, data-less environments seeded through migrations/files—not instant production-data clones. Supavisor transaction pooling is serverless-friendly but has transaction-pooling constraints such as prepared-statement limitations. [Branching](https://supabase.com/docs/guides/deployment/branching), [connections](https://supabase.com/docs/guides/database/connecting-to-postgres), [backups](https://supabase.com/docs/guides/platform/backups) |
| **AWS Aurora PostgreSQL Serverless v2** | You are already deeply on AWS and prioritize mature IAM, VPC isolation, Multi-AZ operations, and enterprise controls | RDS Proxy gives a sound Lambda connection story, but requires VPC plumbing and database-per-PR branching is something you must engineer yourself. [RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html), [RDS backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) |
| **Standard RDS PostgreSQL** | Predictable steady workload, maximum conventionality, or broad compatibility matters more than branching | Excellent managed default, but preview databases and serverless pooling require additional automation and RDS Proxy/PgBouncer |
| **Crunchy Bridge / similar managed Postgres** | You value traditional Postgres operations, portability, and strong PostgreSQL expertise | Less compelling for database-per-preview workflows |
| **Render/Railway/Fly-style platform databases** | Operational simplicity for a small app matters most | Generally weaker than Neon on native branching, recovery controls, or production scaling depth |

Before migration, I’d run a short proof of concept with a sanitized production dump and test:

1. All extensions, roles, migrations, and ORM behavior.
2. Pooled versus direct connections—use direct connections for migrations and pooled connections at runtime.
3. Branch creation, data-sanitization policy, and automatic cleanup when a PR closes.
4. Restore drills, not merely whether the dashboard says backups exist.
5. Latency from every application region and cost under a realistic write-heavy week.
6. A reversible migration using logical replication or a rehearsed dump/restore plus a defined rollback window.

So the short version is: **Neon is my default recommendation for this exact requirement set; Aurora/RDS is my fallback when infrastructure governance outweighs branching convenience, and Supabase wins when you want its broader backend platform rather than just Postgres.**

I’d use **Neon**, assuming its region, extension support, compliance posture, and availability tier fit your production requirements.

It matches your three priorities unusually well:

- **Managed Postgres:** no OS patching or storage provisioning.
- **Serverless connections:** a pooled PgBouncer endpoint supports high connection fan-out—up to 10,000 client connections—while direct connections remain available for migrations and session-dependent workloads. [Neon connection pooling](https://neon.com/docs/connect/connection-pooling)
- **Real database branching:** branches are isolated, typically created in about a second, and can include the parent’s schema and data using copy-on-write storage. Neon provides APIs, GitHub Actions, and Vercel preview integration for branch-per-PR workflows. [Neon branching workflow](https://neon.com/docs/get-started-with-neon/workflow-primer)
- **Recovery:** configurable history retention provides point-in-time restoration and lets you create a branch from an earlier state. Retention and branch allowances depend on the plan. [Neon pricing and restore-window details](https://neon.com/pricing)

A sensible deployment pattern would be:

1. Production uses an always-on or suitably autoscaling compute endpoint.
2. Serverless application traffic uses the pooled URL.
3. Migrations, `pg_dump`, logical replication, and anything requiring session state use the direct URL.
4. CI creates a schema-only or sanitized-data branch for each PR, applies migrations, injects that branch URL into the preview deployment, and deletes the branch when the PR closes.
5. Keep an independent scheduled logical export outside Neon. Point-in-time recovery is excellent operational recovery, but I would not treat a provider’s internal history as the sole disaster or account-compromise backup.

The main Neon caveats are:

- Transaction pooling can break features that depend on session state, temporary tables, session advisory locks, `LISTEN/NOTIFY`, or some prepared-statement behavior. Test your driver and ORM against the pooled endpoint.
- Full-data branches can replicate production personal data into many developer environments. Prefer schema-only branches or sanitize sensitive fields.
- Check every required extension and Postgres setting; managed platforms restrict superuser access and server-level configuration.
- For a serious production workload, review the paid plan’s HA, support, retention, branch limits, and SLA. Neon’s published SLA applies only to eligible Business/Scale plans and specifically to compute endpoints. [Neon SLA](https://neon.com/sla)

What else I considered:

| Provider | Why consider it | Why it isn’t my first choice here |
|---|---|---|
| **Supabase** | Managed Postgres, daily backups/PITR, Supavisor transaction pooling, and PR preview branches. Excellent if you also want Auth, Storage, Realtime, or its Data API. [Connections](https://supabase.com/docs/guides/database/connecting-to-postgres), [branching](https://supabase.com/docs/guides/deployment/branching) | Branches are separate Supabase environments and start without production data by default. That is safer, but less convenient when production-like copy-on-write database branches are the goal. |
| **AWS Aurora PostgreSQL Serverless v2** | Strong AWS integration, private networking, mature operational controls, continuous incremental backups, and 1–35-day PITR. [Aurora backups](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html) | More infrastructure and cost complexity; RDS Proxy is another component; cloning is not as ergonomic as branch-per-PR workflows. Best when AWS governance and reliability controls outweigh developer experience. |
| **RDS PostgreSQL / Cloud SQL / Azure Flexible Server** | Conservative, mature choices with backups, replicas, private networking, and broad enterprise acceptance | Good managed databases, but preview branching generally requires clones, separate instances, or custom automation. Serverless connection handling is also less integrated. |
| **Crunchy Bridge / Aiven** | Strong “normal Postgres” experience, managed operations, good extension support and portability | Less compelling for native ephemeral branching and serverless-first connection management. |

Before committing, I would run a short proof of concept using a restored copy of the database: inventory extensions and roles, test the ORM through Neon’s pooled connection, benchmark representative queries after idle wake-up, exercise a PITR restore, and create/delete preview branches through CI.

For migration, use `pg_dump`/`pg_restore` for a database where a maintenance window is acceptable. For a large or busy system, use logical replication and a brief final write freeze for near-zero-downtime cutover; Neon documents both approaches. [Neon migration options](https://neon.com/docs/import/migrate-intro)

I’d use **Neon**, assuming your workload fits its supported Postgres extensions and available regions.

It most directly matches your requirements:

- Managed Postgres with multi-AZ storage, automated point-in-time recovery, autoscaling, and monitoring.
- A PgBouncer endpoint designed for serverless connection churn, supporting up to 10,000 client connections. Keep the direct endpoint for migrations, `pg_dump`, session locks, and other session-dependent operations. [Neon connection pooling](https://neon.com/docs/connect/connection-pooling)
- Fast copy-on-write database branches, each with an isolated connection string. Their CLI, API, GitHub Actions, and Vercel integration can create a branch per PR and delete it when the preview closes. [Neon branching workflow](https://neon.com/docs/get-started-with-neon/workflow-primer)
- Usage-based pricing and inexpensive short-lived branches. Current paid tiers provide configurable restore windows up to 7 or 30 days, depending on plan. [Neon pricing](https://neon.com/pricing)

The principal caveats are vendor architecture, variable usage-based bills, cold-start latency if you allow production compute to scale to zero, and a shorter standard PITR window than some traditional enterprise configurations. I would disable scale-to-zero for latency-sensitive production workloads and create a separate, independently stored backup outside Neon on a tested schedule. Provider recovery is useful, but it should not be your only recovery path.

What else I considered:

| Provider | When I’d choose it | Why it isn’t my first choice here |
|---|---|---|
| **Supabase** | You also want managed Auth, Storage, Realtime, Edge Functions, and perhaps client-side database access with RLS | Good serverless pooling and PR environments, but preview branches instantiate a broader Supabase environment and are data-less by default; it is more platform than you asked for. [Branching](https://supabase.com/docs/guides/deployment/branching), [connections](https://supabase.com/docs/guides/database/connecting-to-postgres) |
| **Aurora PostgreSQL Serverless + RDS Proxy** | You are already deeply committed to AWS, need private VPC connectivity/IAM, mature compliance controls, and an established AWS operations team | Excellent operationally, but RDS Proxy is separately billed and preview databases require clones/restores and more orchestration; branching is not a first-class developer workflow. [RDS Proxy](https://docs.aws.amazon.com/us_en/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html) |
| **PlanetScale Postgres** | You value its operational model and are comfortable adopting a newer Postgres offering | Backups and PITR look solid, but its documentation says full Postgres branching is still being built; today a populated branch is created by restoring a backup rather than Neon-style instant branching. [Branching](https://planetscale.com/docs/postgres/branching), [backups](https://planetscale.com/docs/postgres/backups) |
| **RDS PostgreSQL / Cloud SQL / Azure Database for PostgreSQL** | You prioritize conventional managed Postgres, predictable infrastructure, private networking, and cloud-native governance over preview ergonomics | Sensible conservative choices, but serverless connection management is more add-on-heavy and database-per-PR branching needs custom automation |

Before committing, I’d run a short proof of concept:

1. Inventory Postgres version, extensions, database size, write rate, large objects, replication slots, and authentication assumptions.
2. Test your ORM through Neon’s pooled endpoint, especially prepared statements, advisory locks, temporary tables, and session-level settings.
3. Create a production-like branch and benchmark p95/p99 latency from the actual application region.
4. Practice both PITR and restoration from an independently stored logical backup.
5. Rehearse migration with `pg_dump`/`pg_restore` for a modest database, or logical replication for a low-downtime cutover. Use the direct, unpooled endpoint for migration tools. [Neon migration guidance](https://neon.com/docs/import/migrate-from-neon)
6. Make preview branches schema-only or sanitized unless developers genuinely need production data.

So: **Neon for the database-only, serverless-plus-branching brief; Supabase if you want the larger backend platform; Aurora if AWS governance and networking outweigh developer-preview convenience.**

I’d use **Neon**, assuming this is a conventional application database and you don’t have an AWS-only networking or compliance requirement.

It fits your priorities unusually well:

- **Serverless connections:** built-in PgBouncer pooling supports up to 10,000 concurrent client connections. Use Neon’s pooled URL for application traffic and the direct URL for migrations, administrative work, and anything requiring session-level behavior. [Neon connection pooling](https://neon.com/docs/connect/connection-pooling)
- **Preview environments:** branches are first-class, inexpensive copy-on-write database branches with their own connection strings. They can be created for each PR and deleted when it closes. [Neon branching workflow](https://neon.com/docs/get-started-with-neon/workflow-primer)
- **Recovery:** paid plans provide configurable point-in-time restore history; the current Launch and Scale plans advertise 7- and 30-day windows respectively. Scheduled snapshots also exist, though that snapshot feature is still labeled beta. [Neon pricing](https://neon.com/pricing), [backup and restore update](https://neon.com/docs/changelog/2025-10-31)
- **Operations:** patching and minor-version updates are handled by Neon, while compute can autoscale or suspend when idle. I would disable scale-to-zero for latency-sensitive production workloads but retain it for previews. [Compute management](https://neon.com/docs/manage/endpoints/)

### What else I considered

| Provider | When I’d choose it | Why it isn’t my first choice here |
|---|---|---|
| **Supabase** | You also want its Auth, Storage, Realtime, REST API, and Edge Functions | Excellent platform, but heavier than needed for database-only use. Preview branches are separate environments, data-less by default, and production-data cloning requires PITR. Branching also has migration/configuration caveats. [Branching docs](https://supabase.com/docs/guides/deployment/branching) |
| **Aurora PostgreSQL + RDS Proxy** | You’re deeply invested in AWS, need private VPC connectivity, mature IAM controls, or established enterprise support | Strong operational choice, but more infrastructure, more pricing dimensions, and preview databases require cloning/orchestration rather than Neon-style branches. RDS Proxy and additional PrivateLink endpoints also cost extra. [RDS Proxy pricing](https://aws.amazon.com/rds/proxy/pricing/) |
| **Standard AWS RDS PostgreSQL** | Predictability and “boring managed Postgres” matter more than branching or elastic serverless behavior | Probably the conservative runner-up, but preview branching is something you would build yourself. Lambda/serverless traffic normally means adding RDS Proxy. |
| **Crunchy Bridge** | You prioritize upstream-Postgres fidelity, portability, and strong Postgres specialists | Very credible managed Postgres: daily base backups, continuously streamed WAL, and ten-day retention by default. Its connection and environment story is less purpose-built for bursty serverless previews than Neon’s. [Crunchy Bridge backups](https://docs.crunchybridge.com/concepts/backups) |
| **Render/Railway/Fly-managed options** | The database is small and you want it beside an application already hosted there | Convenient, but branching, recovery depth, and database-specific operational controls are generally less compelling for this requirement set. |

### Conditions that could change the recommendation

I’d choose Aurora/RDS instead if the database is large and continuously busy, relies on extensions Neon doesn’t support, needs strict private networking, or sits inside an AWS architecture where cross-provider latency and egress outweigh developer convenience. I’d choose Supabase if you intend to adopt the rest of its backend platform rather than merely its Postgres service.

Before migrating, I’d verify:

1. Required extensions, Postgres version, collations, logical replication, and any superuser-dependent jobs.
2. Peak compute, working-set size, write rate, connection behavior, and acceptable recovery window.
3. Whether preview branches may contain production data; if so, masking and access controls are mandatory.
4. A real restore drill—not merely confirmation that backups appear in a dashboard.
5. A separate periodic encrypted `pg_dump` in storage you control. Provider PITR protects against operator mistakes, but an independent logical backup protects against provider/account-level failure and preserves portability.

My practical setup would be: **Neon paid plan, always-on production compute, pooled application URL, direct migration URL, PITR sized to your recovery policy, automated PR branches with expiry, and an independent nightly logical backup.**

I’d use **Neon**, assuming this is a typical web application rather than a heavily regulated or unusually high-throughput system.

It aligns unusually well with all three requirements:

| Requirement | Neon |
|---|---|
| Managed operations | Automated maintenance and point-in-time recovery |
| Serverless connections | Managed PgBouncer endpoint; up to 10,000 client connections |
| Edge/JS runtimes | Optional HTTP/WebSocket driver |
| Preview environments | Fast, copy-on-write database branches with API, CLI, GitHub, and Vercel integration |
| PostgreSQL compatibility | Real PostgreSQL, but with managed-service restrictions |

The branching is the deciding factor. A branch is isolated, takes roughly a second to create regardless of database size, initially shares storage with its parent, and can scale to zero when idle. It can contain production-like schema and data or be schema-only. That is considerably nicer for per-PR environments than provisioning independent databases and restoring dumps. [Neon branching workflow](https://neon.com/docs/get-started-with-neon/workflow-primer), [preview-environment integrations](https://neon.com/docs/guides/branching-intro)

For application traffic, use Neon's pooled PostgreSQL URL. For short, one-shot TypeScript queries in edge/serverless runtimes, its HTTP driver can avoid TCP connection management entirely; WebSockets support interactive transactions. [Connection pooling](https://neon.com/docs/connect/connection-pooling), [serverless driver](https://neon.com/docs/serverless/serverless-driver)

What else I’d consider:

- **AWS Aurora PostgreSQL Serverless v2 + RDS Proxy:** My second choice if you are already deeply invested in AWS, need private VPC connectivity, mature IAM controls, or have stringent procurement/compliance requirements. RDS Proxy provides managed pooling and failover handling. The disadvantage is substantially more infrastructure and no equivalent first-class, cheap per-PR database branching. [AWS RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.howitworks.html)

- **Supabase:** A strong choice if you also want authentication, storage, realtime subscriptions, or its Data API. It supplies daily backups, paid-plan PITR, branching, and Supavisor transaction pooling specifically for serverless workloads. I would not select the whole Supabase application platform solely to host an ordinary PostgreSQL database, though. [Database overview](https://supabase.com/docs/guides/database/overview), [connection options](https://supabase.com/docs/guides/database/connecting-to-postgres)

- **PlanetScale Postgres:** Promising, with PgBouncer, automated backups, and isolated branches. Its current PostgreSQL branching workflow is less mature: ordinary new branches can be empty, production data comes through backup restoration, storage is independent, and schema changes must currently be applied to production manually rather than merged automatically. [PlanetScale branching](https://planetscale.com/docs/postgres/branching), [backups](https://planetscale.com/docs/postgres/backups)

- **RDS PostgreSQL, Google Cloud SQL, or Azure Database for PostgreSQL:** Conservative, credible managed PostgreSQL choices. I’d favor one if organizational standardization and cloud-native networking outweigh preview branching. Preview databases would generally require automation around clones, snapshots, or dumps.

Before committing to Neon, I would run a short proof of concept covering:

1. Extension compatibility, superuser-dependent operations, parameter settings, and any filesystem assumptions. Managed Neon does not expose the host or a true PostgreSQL superuser, and only supported extensions can be installed. [Compatibility details](https://neon.com/docs/reference/compatibility)
2. Real query latency after idle compute resumes, plus sustained production load at the intended compute size.
3. ORM behavior through transaction pooling—session-level state, temporary tables, prepared statements, and advisory-lock patterns deserve explicit tests.
4. Restore-window and recovery-time requirements on the paid plan you intend to buy.
5. Data governance for preview branches. Do not casually clone customer PII into every pull request; use schema-only branches or sanitized seed data where appropriate.
6. Region availability, support SLA, private networking, and worst-case cost under sustained rather than bursty load.

For migration, I’d use `pg_dump`/`pg_restore` for a database small enough to tolerate a maintenance window. For a larger or busier system, Neon supports PostgreSQL logical replication for a low-downtime cutover. Keep the old VM read-only and recoverable until checksums, row counts, critical queries, background jobs, and restore procedures have all been verified. [Neon migration options](https://neon.com/docs/import/migrate-intro)

My short version: **Neon is the best product fit; Aurora is the organizational-risk fit.** I would choose Aurora instead only if your networking, compliance, workload maturity, or existing AWS operations meaningfully outweigh the value of effortless preview branches.

I’d use **Neon**, assuming your workload and required Postgres extensions pass a compatibility test.

It aligns unusually well with all three requirements:

- It is managed Postgres with configurable point-in-time recovery and automated snapshots.
- Its pooled PgBouncer endpoint is designed for bursty/serverless workloads and supports up to 10,000 client connections. JavaScript runtimes can also use Neon’s HTTP/WebSocket driver. [Connection pooling](https://neon.com/docs/connect/connection-pooling) · [Serverless driver](https://neon.com/docs/serverless/serverless-driver)
- Branches are isolated, copy-on-write databases created in roughly a second. They can be created automatically per pull request and scaled to zero when idle—exactly the preview-environment model you described. Schema-only branches are available when copying production data would be unsafe. [Branching workflow](https://neon.com/docs/get-started-with-neon/workflow-primer) · [Branching guide](https://neon.com/docs/guides/branching-intro)

For production, I would start on Neon Launch only if a seven-day recovery window and its operational guarantees are sufficient. Scale offers up to 30 days of restore history, private networking, IP restrictions, observability export, and an SLA. Current limits and pricing should be modeled against your actual compute hours, change volume, and number of simultaneous preview branches. [Neon pricing](https://neon.com/pricing)

What else I considered:

| Provider | Where it fits | Why it would not be my first choice here |
|---|---|---|
| **Supabase** | Strong if you also want Auth, Storage, Realtime, or its Data API. Supavisor transaction pooling is intended for serverless functions, and database branching is supported. [Database overview](https://supabase.com/docs/guides/database/overview) | More application platform than you asked for. Connection modes and IPv4/IPv6 choices add some complexity. [Connection guide](https://supabase.com/docs/guides/database/connecting-to-postgres) |
| **Aurora PostgreSQL + RDS Proxy** | Best if you are already deeply committed to AWS, need mature IAM/VPC integration, or have stricter enterprise controls. RDS Proxy handles bursty connections well. [RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.howitworks.html) | Preview databases require Aurora clones and additional automation; they are much heavier than first-class Neon branches. More components and cost management. |
| **Crunchy Bridge** | Excellent “boring Postgres” option with strong PostgreSQL expertise, daily physical backups, WAL shipping, and backup forks. [Backups](https://docs.crunchybridge.com/concepts/backups) | Backup forks are useful, but its branching workflow is less optimized for ephemeral per-PR environments; the connection story is more conventional. |
| **RDS PostgreSQL / Cloud SQL / Azure Database for PostgreSQL** | Conservative choice when cloud-native networking, procurement, and organizational familiarity dominate. | Managed operations and PITR are solid, but serverless pooling and database-per-preview branching generally require extra products and custom automation. |

Two cautions would shape the rollout:

1. **Do not treat branching as your only backup strategy.** Configure the required PITR window, test restoration regularly, and keep periodic encrypted logical dumps in a separate account or provider. This protects against credential compromise, operator mistakes, and provider-level failures.

2. **Do not automatically copy sensitive production data into every preview.** Prefer schema-only branches plus synthetic fixtures, or run a masking step immediately after branch creation.

Before committing, I would run a rehearsal using a recent `pg_dump`: verify extensions, roles, ownership, sequences, large objects, migration tooling, transaction-pooling compatibility, query latency, and restore behavior. Transaction pooling can affect session-dependent features such as prepared statements, temporary tables, advisory locks, and session-level settings, so migrations and administrative jobs should use the direct endpoint while serverless application traffic uses the pooled one.

My short version: **Neon for the stated requirements; Aurora PostgreSQL if AWS governance and enterprise networking matter more than elegant preview branching; Supabase if you want its broader backend platform as well as Postgres.**

I’d use **Neon**, assuming this is a normal web/SaaS workload and you don’t require the database to sit inside your own VPC.

It aligns unusually well with all three requirements:

- It is managed Postgres, with multi-AZ WAL durability and point-in-time restoration. Restore history is plan-dependent: currently 7 days on Launch and 30 days on Scale. [Architecture](https://neon.com/docs/introduction/architecture-overview) · [Plans](https://neon.com/pricing)
- Its PgBouncer endpoint is designed for connection-heavy/serverless applications and supports up to 10,000 client connections. JavaScript/TypeScript workloads can also query over HTTP or WebSockets. [Pooling](https://neon.com/docs/connect/connection-pooling) · [Serverless driver](https://neon.com/docs/serverless/serverless-driver)
- Branching is a first-class, copy-on-write database primitive. A pull request can get an isolated, production-like database branch, migrations can run against it, and the branch can be removed when the PR closes. [Branching guide](https://neon.com/docs/guides/branching-intro) · [Preview workflow](https://neon.com/blog/branching-with-preview-environments)

The important caveats:

- “Time travel” is not a complete backup policy. I would still schedule encrypted `pg_dump` exports to storage controlled by your organization and test both provider restoration and independent restoration.
- Transaction pooling can conflict with session-level features, some prepared-statement behavior, advisory locks, `LISTEN/NOTIFY`, and migration tooling. Give the application a pooled URL, but use a direct URL for migrations, replication, and `pg_dump`.
- Autosuspend introduces cold-start latency. I would keep production compute always active if latency is important, while letting preview branches suspend.
- Branches copied from production contain production data. Prefer schema-only branches or sanitized seed data unless preview infrastructure has production-grade access controls.
- PrivateLink, IP restrictions, longer restore windows, SLA, and stronger observability are higher-tier features. Neon’s current SLA applies only to Business/Scale compute endpoints, so read its scope rather than treating “managed” as synonymous with comprehensive uptime coverage. [Security](https://neon.com/docs/security/security-overview) · [SLA](https://neon.com/sla)

What else I’d seriously consider:

| Provider | When I would choose it instead | Main compromise |
|---|---|---|
| **AWS Aurora PostgreSQL + RDS Proxy** | Everything already runs in AWS, private networking/IAM/governance matter more than developer ergonomics, or the workload is business-critical enough to favor AWS’s operational surface | Strong backups and connection pooling, but no comparable native per-PR database branching; more components and cost. [RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.howitworks.html) · [Retained backups](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.Retaining.html) |
| **Supabase** | You also want hosted Auth, Storage, Realtime, generated APIs, or edge functions | Excellent application platform, but heavier if you only need Postgres. Preview branches are separate environments and data-less by default; current branching still has migration/merge limitations. [Database](https://supabase.com/docs/guides/database/overview) · [Branching](https://supabase.com/docs/guides/deployment/branching) |
| **Crunchy Bridge** | You value conservative, Postgres-focused operations, accessible pgBackRest backups, multi-cloud placement, and support from Postgres specialists | Good pooling and backup-derived forks, but preview branching is less immediate and integrated than Neon’s copy-on-write model. [Backups](https://docs.crunchybridge.com/concepts/backups) |
| **Cloud SQL / Azure Database for PostgreSQL / conventional RDS** | Procurement, compliance, or cloud standardization dictates the provider | Dependable managed Postgres, but preview databases usually require full clones, automation, and more spend. |

Before committing, I’d run a short proof of concept: restore a backup, create and destroy a PR branch through CI, run the actual ORM under a burst of serverless invocations, verify every required extension, and benchmark a production-sized clone. For migration, use `pg_dump`/`pg_restore` if a maintenance window is acceptable; for a larger or low-downtime move, use logical replication, validate row counts/sequences, then perform a brief write freeze and cut over. Neon documents both approaches. [Migration options](https://neon.com/docs/import/migrate-intro)

So the short answer is: **Neon for the stated priorities; Aurora plus RDS Proxy if private AWS integration and operational conservatism outweigh branching.**

Neon byłby moim wyborem. To zarządzany Postgres zbudowany właśnie pod te trzy wymagania naraz: backupy i point-in-time restore są wbudowane, ma natywny connection pooler (endpoint z PgBouncerem) więc funkcje serverless/Lambda nie zabijają puli połączeń, a branching to ich flagowa funkcja - branch bazy (copy-on-write, sekundy) na każdy PR pod preview environment, nie osobny mechanizm doklejony później. Główny kompromis: scale-to-zero na mniej aktywnych branchach oznacza cold start przy pierwszym zapytaniu, a przy większym ruchu koszt trzeba pilnować, bo model rozliczeń jest inny niż płaski VM.

Co jeszcze brałem pod uwagę:

- **Supabase** - też Postgres z branchingiem, ale branching jest nowszy i płatny od wyższego planu, a produkt dokłada auth/storage/realtime, które są zbędne, jeśli chcecie tylko bazy.
- **AWS RDS / Aurora Serverless v2** - najbardziej dojrzały i sensowny, jeśli już siedzicie w AWS, ale brak natywnego branchingu i połączenia z Lambdy/funkcji serverless wymagają RDS Proxy, czyli dodatkowego elementu do utrzymania - de facto wracacie do tego, od czego uciekacie.
- **PlanetScale** - branching mają dopracowany od lat, ale to dla MySQL; ich oferta Postgres jest świeża i nie ma za sobą tej samej historii.
- **Crunchy Bridge / Render / Railway** - solidny zarządzany Postgres z backupami, ale bez brancingu, więc nie spełniają trzeciego wymagania.
- **CockroachDB** - odpadł od razu, bo to inny model spójności i nie jest to prawdziwa kompatybilność z Postgresem (rozszerzenia, niektóre typy), przerost formy nad potrzebą przy migracji z jednej instancji VM.

Jeśli macie już duży stack na AWS albo wymagania compliance ciągnące was w tamtą stronę, RDS/Aurora byłby bezpieczniejszym wyborem kosztem brancingu. W przeciwnym razie stawiałbym na Neon.

Postawiłbym na **Neon**. Ma natywny branching bazy (kopiuje się przez copy-on-write, więc branch pod PR-a powstaje w sekundy, nie trzeba go ręcznie seedować), oddzielny connection pooler (PgBouncer w trybie transakcyjnym) dla połączeń serverless/edge, autoscaling do zera na czas bezczynności i point-in-time restore w standardzie. To wprost adresuje twoje trzy wymagania: backupy, sensowną historię połączeń dla serverless i branching pod preview environments.

Co jeszcze brałem pod uwagę:

- **Supabase** - też ma branching i backupy, ale to cały framework (auth, storage, realtime) doklejony do Postgresa; jeśli chcecie gołej bazy bez przejmowania reszty stacku, to bagaż, którego nie potrzebujecie.
- **AWS RDS / Aurora Serverless v2** - solidny wybór jeśli już jesteście głęboko w AWS i chcecie jednego dostawcy do wszystkiego, ale zero branchingu z pudełka i "serverless" tu znaczy autoscaling capacity, nie scale-to-zero ani lekki connection story - nadal potrzebujecie RDS Proxy albo PgBouncera osobno.
- **PlanetScale for Postgres** - nowe (branching miały wcześniej tylko dla MySQL), mniej dojrzałe dla Postgresa niż Neon, ostrożnie bym na to teraz stawiał produkcyjnie.
- **CockroachDB / Crunchy Bridge** - mocne pod HA i compliance, ale bez brachingu jako pierwszorzędnej funkcji, więc odpada dla waszego use case'u z preview environments.

Główny kompromis przy Neon: to młodszy gracz niż RDS, więc jeśli macie twarde wymagania compliance/enterprise (SOC2 już mają, ale np. dedykowany VPC peering jest bardziej ograniczony niż w AWS), warto to zweryfikować pod wasze konkretne wymogi zanim zaczniecie migrację.

Neon - branching tam jest natywne (copy-on-write, sekundy, tanie), a pooling pod serverless jest wbudowany w connection string, nie trzeba tego domontowywać. Największy trade-off: to młodszy gracz, więc track record na bardzo dużych obciążeniach jest cieńszy niż przy RDS/Aurora, i tracisz nieco natywnej integracji z resztą stacku jeśli siedzicie głównie w AWS.

Co jeszcze brałem pod uwagę i czemu odpadło:
- **Supabase** - branching już jest, ale to pełny klon projektu, nie copy-on-write, więc wolniejszy i droższy per branch; do tego dostajesz cały dodatkowy platform (auth, storage, realtime), którego możecie nie potrzebować.
- **PlanetScale** - branching to ich rodowód, ale historycznie MySQL-first; oferta Postgres jest nowsza i mniej sprawdzona w boju.
- **AWS RDS / Aurora Serverless v2** - najbardziej sprawdzone, backupy top, ale brak natywnego branchingu i pod serverless trzeba doinstalować RDS Proxy, więcej ręcznej roboty.
- **CockroachDB** - świetny do skali rozproszonej globalnie, ale to przerost formy nad treścią dla was i nie wszędzie w pełni kompatybilny na poziomie protokołu.

Powiedz, jeśli chcesz żebym rozpisał plan migracji z tej maszyny VM na Neon, albo jeśli któryś z odrzuconych ma dla was jednak znaczenie (np. już jesteście mocno w AWS).

Neon - Postgres zbudowany pod dokładnie ten zestaw wymagań: branching baz danych na preview environments to ich flagowa funkcja (branch = copy-on-write, sekundy, nie kopiuje całych danych), connection pooling (PgBouncer wbudowany) rozwiązuje sensownie problem serverless (Lambda/Vercel/Cloudflare Workers bijące w limit połączeń), plus PITR i automatyczne backupy z pudełka.

Co jeszcze brałem pod uwagę:
- **Supabase** - też ma teraz branching i też jest managed Postgres, ale to głównie BaaS (auth, storage, realtime) z bazą jako jednym z elementów; sensowny wybór jeśli i tak chcecie te dodatki, przesada jeśli chcecie tylko bazę.
- **AWS Aurora Serverless v2 / RDS** - najbardziej dojrzałe i "nudne w dobrym sensie", ale brak natywnego branchingu (trzeba by ręcznie snapshotować/klonować) i connection pooling wymaga doklejenia RDS Proxy - więcej ruchomych części do utrzymania, czyli częściowo ten sam problem co teraz.
- **PlanetScale** - dodali Postgres, ale oferta jest nowsza i mniej sprawdzona niż ich MySQL; branching mają, ale zostawiłbym to na później, aż dojrzeje.

Dla migracji z samopisanej VM-ki Neon daje najmniej dodatkowej roboty utrzymaniowej przy pełnym pokryciu wszystkich trzech wymagań na raz.

Neon. To dokładnie w ten worek wymagań: zarządzany Postgres, ciągłe backupy z point-in-time recovery, connection pooling (PgBouncer wbudowany) pod ruch serverless, i branching baz danych 1:1 do naszych preview environmentów (branch = kopia danych, nie tylko schemat).

Co jeszcze brałem pod uwagę:
- **Supabase** - też ma branching i managed Postgres, ale to szerszy pakiet (auth, storage, realtime), którego nie potrzebujemy, a sam branching jest mniej dojrzały niż w Neon.
- **RDS / Aurora Serverless v2** - najbezpieczniejszy wybór jeśli już jesteśmy głęboko w AWS, ale bez natywnego branchingu baz i z droższym, cięższym connection pooling story (RDS Proxy trzeba dokładać osobno).
- **PlanetScale** - dobry branching, ale to MySQL (Vitess), nie Postgres, więc migracja byłaby większa niż migracja "tylko hosta".
- **Railway / Render** - proste i tanie, ale to bardziej "VM z ładniejszym UI" niż faktycznie managed serverless-native Postgres, więc nie rozwiązuje głównego problemu (kto patchuje).

Główny kompromis przy Neon: scale-to-zero i cold starty potrafią dodać opóźnienie przy rzadko używanych branchach, więc branch produkcyjny/staging warto trzymać "always on".