Neon vs Amazon RDS PostgreSQL: FAQ

Amazon RDS for PostgreSQL is the default Postgres option in AWS for many teams. We often receive questions about how Neon compares to it—this FAQ is a great way to quickly understand how Neon approaches things differently and whether it can add value to your team.

TL;DR: Neon and Amazon RDS are essentially different

Amazon RDS is a reliable, instance-based managed database service, but it lacks the agility and modern developer-focused tooling that today’s teams need. Neon, on the other hand, delivers Postgres as a serverless platform designed to help teams of all sizes ship software faster and more efficiently by eliminating database bottlenecks.

What motivates teams migrating from RDS to Neon?

Every use case is different, but teams migrating from RDS often come to us looking to solve one or more of these problems:

High costs for non-production environments

Non-production instances for dev, test, and staging environments incurred 24/7 costs unless manually paused, and required manual synchronization of data across instances.

Neon solves this via database branching. Teams can instantly create isolated environments as branches, without duplicating data, and scaling-to-zero.

Data consistency problems

Syncing seed data and testing datasets across multiple RDS instances was manual and error-prone, leading to inconsistencies and unreliable test environments.

Neon branches also solve this, since they can sync with the parent database in one API call.

Limited cost-efficiency in scaling

RDS’s fixed costs for both compute and storage kept growing, with no easy solution for scaling storage down or managing compute costs.

Neon autoscales compute and storage up and down automatically, billing per true usage.

Operational complexity in multi-tenancy

Scaling a database-per-tenant architecture in RDS was getting difficult—the options were 1) fitting multiple databases in one large instance thus creating a single point of failure, 2) managing many small instances and hiring a dedicated DevOps engineer.

Neon solves this via its project-per-customer model: projects have instance-level isolation, can be managed via API, are instant to provision, and autoscale.

How is Neon’s architecture different from RDS?

The core differences between both platforms can be well understood when comparing their architectures.

Neon has a serverless architecture built on three pillars:

Separation of storage and compute. Differently from RDS, Neon separates storage and compute into distinct layers. The storage layer manages the database’s persistent data independently of compute resources. Compute nodes can be dynamically created, scaled, or terminated without impacting the underlying storage.
WAL-based storage with transaction history and built-in HA. Neon’s storage layer is built around Postgres’ Write-Ahead Logging (WAL). It preserves the complete history of all transactions, which enables innovative features like instant database branching and instant point-in-time recovery. It combines SSDs for fast performance redundant in multiple AZs, and an object storage layer (e.g., S3) for baked-in durability.
Ephemeral compute endpoints that autoscale. Neon’s compute nodes are “provisioned” nearly instantaneously. They scale CPU and memory dynamically with demand, scaling down to zero automatically when inactive, and being rebooted again in 500 ms. Multiple compute endpoints can connect to the same storage, and multiple environments (e.g., dev, test, staging) can operate independently via branching while also sharing the same storage node.

In comparison, RDS uses a traditional instance-based architecture where storage and compute are tightly coupled. Storage in RDS is backed by an EBS volume, which stores the database’s persistent data, while compute runs on an EC2 instance. This RDS instance (EBS + EC2) is treated as a single, indivisible unit, which has many implications:

Starting new instances takes time, often several minutes or more.
Compute instances run continuously by default, incurring costs even when idle.
Pausing instances requires manual intervention, and rebooting takes time.
Resizing compute resources often requires downtime.
Scaling storage up has limitations, e.g. only one resize is allowed every 6 hours to stabilize the underlying EBS volume.
Scaling storage down is impossible. To reduce storage usage, the entire database must be migrated to a new, smaller storage volume.

	Neon	Amazon RDS
Architecture	Serverless. Storage and compute are separate layers	Instance-based. Storage and compute are tightly coupled
Scaling	No provisioning necessary. Compute autoscales according to load, with scale to zero. Storage scales up and down according to data size	Necessary to provision compute and storage in advance. Compute can be resized manually, often requiring downtime. Storage can be scaled up once every 6 hours, never resized down
Storage	Built on SSDs and object storage (S3) with multiple AZs for redundancy	Backed by EBS volumes
Compute	Instant provisioning of compute nodes. CPU/memory autoscales according to load. Compute nodes scale down to zero when inactive. Multiple compute nodes can be attached to the same storage	Fixed EC2 instance
Billing model	Subscription plans with pay-per-usage	Allocation-based
Transaction history	WAL-based. Keeps full transaction history to support database branching via copy-on-write, time-travel queries, instant PITR	N/A
Connection pooling	Native, built on pgBouncer. Up to 10,000 connections	Requires RDS Proxy

How is Neon storage different from RDS?

Neon’s storage architecture is significantly more complete vs. RDS, as it incorporates many more features if compared to an EBS volume. Neon integrates object storage (S3) for durable data storage, dynamic components built on SSDs to manage and serve data with fast performance, enables branching via copy-on-write, and is completely decoupled from compute.

Postgres’ WAL, or Write-Ahead Logging, is central to Neon’s architecture because it fundamentally enables us to transform how data is managed. By using WAL as the core storage mechanism, all changes can be recorded sequentially before they are applied to the database. This is the innovation behind some of the best Neon features, like copy-on-write database branching.

This is how the different storage elements work together:

Object Storage (S3) provides the primary and long-term data repository.
Safekeepers handle Write-Ahead Log (WAL) replication, ensuring data is redundantly stored across multiple Availability Zones (AZs). This component uses SSDs to enhance the speed and reliability of WAL data handling and replication processes.
Pageservers act as a disk cache and storage manager, using SSDs to quickly retrieve and serve data to compute nodes. This layer significantly boosts performance by providing fast access to the most recently accessed data, optimizing read and write operations within Neon’s architecture.

How long does it take to provision a database in Neon vs RDS?

Neon is much faster than RDS in terms of database provisioning times due to its serverless architecture. Neon provisions databases in approximately 200 milliseconds; in contrast, Amazon RDS typically requires a minimum of 10 minutes to provision a database, often more, as it involves setting up an EC2 instance and attaching an EBS volume.

How does scalability compare in Neon vs RDS?

Neon’s serverless approach allows for hands-off, automatic scaling both for compute and storage compared to the instance-based architecture of RDS.

	Neon	Amazon RDS
Compute	Autoscales CPU/memory in response to load. Scales to zero when not in use.	Relies on manual resizes / pausing. Resizes often require downtime. Instances take time to resume.
Storage	Scales up and down according to data size.	Storage scaled up once every 6 hours. It cannot be scaled down.

Is Neon’s pricing model similar to RDS’s?

Amazon RDS uses the billing model typical of AWS, where the monthly bill reflects different items like compute capacity, storage allocated, data transfer, and additional features and services like support.

In contrast, Neon employs a subscription-based model where users select from multiple plans that include a predefined amount of compute and storage usage within a monthly fee. Any usage exceeding the included amount is billed separately at the end of the month. For enterprise customers, Neon also provides custom plans and annual contracts.

It’s important to note that in Neon, compute consumption is calculated based on actual usage via compute hours, determined by the compute capacity used by your workload and the duration it runs. Regarding storage, Neon’s per-GB pricing effectively extends further than RDS:

Multiple compute endpoints and branches can share the same storage without duplicating data, thanks to Neon’s use of copy-on-write technology.
Multi-AZ availability and S3 backups are also integrated into Neon’s design.

How do Neon and RDS handle high availability and fault tolerance?

While RDS relies on synchronous replication to achieve HA, Neon provides it natively through a stateless architecture with components distributed across multiple AZs. In more detail:

RDS offers high availability through Multi-AZ deployments, where data is synchronously replicated to a standby instance in a different AZ. In the event of a failure, RDS automatically performs a failover to the standby, minimizing downtime. However, this approach requires duplicating the entire dataset and configuration in a secondary instance, resulting in a 2x higher deployment cost.
Neon separates storage and compute layers, which already enhances resilience. Since the compute layer is stateless, compute failures are automatically resolved within seconds. The storage layer consists of components distributed across multiple AZs, ensuring data durability and operational continuity. Additionally, Neon stores the primary, long-term copy of data in object storage (e.g., S3), offering 99.999999999% durability and safeguarding against permanent data loss.

How does Neon’s pooling approach differ from RDS Proxy?

Neon integrates connection pooling directly into its platform using PgBouncer, supporting up to 10,000 concurrent connections by default. This pooler is included in all Neon pricing plans, even the free tier, with no extra charges.

In contrast, RDS Proxy is a separate managed service requiring additional setup and maintenance. RDS Proxy is also billed separately based on the number of active connections and data processed and often doesn’t work that well for the volume of connections typical of serverless architectures.

How does Neon handle non-production environments vs RDS?

Non-production environments are one of the best applications for Neon branches. Since Neon supports the instant creation of isolated database branches using a copy-on-write mechanism, developers can quickly set up environments that mirror production data with little to no maintenance required. Teams don’t have to manage seed data or keep environments in sync; branches can be reset to the parent with one API call, scale to zero automatically when inactive, and their creation/deletion can be fully integrated into CI/CD pipelines.

“Neon’s branching paradigm has been great for us. It lets us create isolated environments without having to move huge amounts of data around. This has lightened the load on our ops team, now it’s effortless to spin up entire environments.” Jonathan Reyes, Principal Engineer at Dispatch – Read case study

In contrast, setting up non-production environments in RDS typically involves manual configuration of separate instances, which is time-consuming and requires additional management effort. Testing datasets need to be manually loaded and kept in sync across environments, and instance pausing must be scheduled to save compute costs during off hours.

Can I use Neon and Amazon RDS together in a hybrid approach?

Yes! It’s common to use Neon and Amazon RDS together, keeping production databases in RDS while dev, test, and staging environments are managed in Neon. This setup allows you to optimize non-production workflows without the need for a full migration of your production database. See this guide for more information.

Is Neon’s approach to multitenancy different than RDS?

Yes. In RDS, scaling multitenant architectures requires either fitting multiple databases within a single instance (causing performance bottlenecks and creating a single point of failure) or managing thousands of small instances, which demands significant DevOps resources and inflates costs.

“Our customers require their data to live in an isolated database, but implementing this in RDS was cumbersome and expensive. We switched over to Neon to reduce costs and operational overhead” – Joey Teunissen, CTO at OpusFlow – Read case study

But Neon has an advantage: its serverless architecture. With Neon, each tenant can have their own dedicated project, which functions as an isolated “instance” without the management overhead.

This design enables instance-level isolation, meeting strict data privacy requirements for B2B SaaS platforms and regulatory compliance across regions by placing tenant data in location-specific projects.
Unlike RDS, Neon’s scale-to-zero automatically pauses inactive projects, ensuring cost efficiency
Neon supports rapid provisioning (under a second) and can handle fleets of thousands of databases with minimal operational burden, thanks to its API-first design and autoscaling capabilities.

How does Neon compare to RDS in terms of compliance?

Both Neon and Amazon RDS comply with the most demanded industry standards, including CCPA, GDPR, ISO 27001, ISO 27701, SOC 2, SOC 3, and HIPAA.

✨Get $100 in credits: Neon offers a Free Plan, and we’ll discount up to $100 off your first invoice when you upgrade. Claim the offer by signing up through this link.

If you have any further questions, we’ll be happy to answer them. Book time with our team.