Neon vs RDS Postgres

Serverless Postgres.

Overview

Neon and AWS RDS for Postgres are two managed-Postgres options with very different scaling models. Neon is serverless with native branching (separation of compute and storage, branch-per-feature workflow, scale-to-zero); RDS is the AWS-native managed Postgres (instance-based scaling, multi-AZ replicas, tight AWS integration). The right answer depends on whether serverless ergonomics or AWS-native simplicity matters more.

• Neon: serverless plus branching. Compute/storage separation, branch-per-feature for schema work, scale-to-zero on idle. Default when developer-experience matters.
• RDS: AWS-native Postgres. Instance-based scaling, multi-AZ replicas, VPC/IAM/CloudWatch integration. Default for AWS-only stacks.
• Operational fit per team. Existing AWS investment biases toward RDS; greenfield apps where branching is a developer-experience win bias toward Neon.
• Per-database choice. Different databases may pick differently. Document the rationale per database.

The approach

Workload-driven choice, per-team operational fit considered, documented rationale per database. The discipline is making the managed-Postgres choice once with a written reason rather than running both for the same workload.

• Workload-driven. Postgres platform per database. Reality drives the answer.
• Neon for serverless plus branching. Greenfield apps, dev-friendly schema migrations, scale-to-zero workloads. Default when DX matters.
• RDS for AWS-native simplicity. AWS-only stack, multi-AZ replication. Default for typical SaaS on AWS.
• Operational fit plus documented rationale. Team workflow considered; per-database rationale captured. Future migrations have a paper trail.

Why this compounds

The right Postgres platform compounds across years. Database patterns and team expertise align with the platform; cross-database tooling (backup strategy, schema-migration workflow, observability) gets reused. By year two the choice is automatic per database.

• Better operational fit. Platform matches team and workload. Velocity stays high.
• Workload-driven decisions. Replaces tribal preference with documented rationale. Quality of choice improves.
• Better engineering velocity. Right platform means schema migrations and capacity changes are predictable. Iteration speed increases.
• Year-one investment, year-two habit. First decision is the investment; subsequent databases inherit the patterns.