Neon vs. Aurora Serverless v2: FAQ
Neon and Aurora Serverless share many similarities—Neon’s architecture was, in fact, inspired by Aurora. However, the two services differ in significant ways. Let’s explore these differences by answering common questions.
Is Neon a serverless database like Aurora Serverless?
Yes, Neon is a serverless database like Aurora Serverless; in many ways (e.g., autoscaling, provisioning, cold start times, and pooling performance), it’s more serverless than Aurora. Read more about what serverless means to us.
Like Aurora, Neon’s architecture decouples storage and compute, but Neon takes it further with a unique storage design that delivers greater serverless agility, instant provisioning, and innovative features like database branching.
Is Neon also compatible with MySQL and Postgres?
No, Neon is natively a Postgres service. Unlike Aurora, Neon’s storage and autoscaling designs are custom-built for Postgres, leveraging advanced optimizations of Postgres’ Write-Ahead Log (WAL).
By re-architecting the WAL as a transaction journal and integrating techniques like HyperLogLog-based working set size estimation, Neon offers a performant autoscaling that instantly matches workload demands while maintaining in-memory efficiency.
What are the differences in cold starts?
Thanks to its unique architecture, Neon scales to zero during inactivity while providing near-instant cold start times, averaging around 500 ms. Aurora Serverless v2, which introduced scaling to zero in November 2024, can take up to 15 seconds to restart from zero.
How does pricing compare?
Our customers report significantly lower bills—up to 80% less—when migrating from Aurora Serverless v2 to Neon. This cost advantage comes from several key factors:
- Subscription-based pricing plans. Neon offers plans that include a generous usage allowance within a flat monthly fee, making it highly affordable for workloads that stay within those limits. Neon also has a Free plan.
- Lower compute unit costs. Even beyond the included usage, Neon remains cost-effective. Its compute units (CUs) are priced at one-quarter the cost of Aurora’s capacity units (ACUs) for equivalent vCPU resources, providing more computing power per dollar.
- Responsive autoscaling and scale-to-zero. Neon’s autoscaling algorithm adjusts resources dynamically, scaling down to zero during inactivity. This ensures you only pay for active usage, unlike Aurora, which may remain “stuck” at a minimum level of ACUs.
How do both autoscaling engines differ?
The autoscaling architectures of Neon and Aurora Serverless v2 share the concept of decoupling compute and storage but differ significantly in implementation. Aurora Serverless v2 adjusts compute resources in fixed 0.5 ACU increments (~0.125 vCPU, 0.5 GB memory), with a cautious approach to scaling down to avoid buffer pool disruption. While it now supports scaling to zero, scaling down remains a slower, conservative process.
Neon’s autoscaling is designed for responsiveness, especially during scaling down—offering a faster, more efficient experience compared to Aurora. It dynamically allocates resources based on real-time metrics, such as CPU load, memory usage, and the working set size in its Local File Cache (LFC). Neon uses Compute Units (CUs), with 1 CU equaling 1 vCPU and 4 GB memory, and scales in increments of 0.25 CU.
The technical details:
Scaling decisions
Neon’s algorithm ensures optimal performance by selecting the highest resource demand from three metrics:
- CPU load average. Neon keeps the 1-minute average CPU load at or below 90% of available capacity.
- Memory usage. Neon maintains memory usage at or below 75% of allocated RAM.
- Working set size. Neon fits frequently accessed data within 75% of the compute’s RAM allocated to the LFC. Read more about this technique.
Polling frequency
Frequent metric polling allows Neon to react quickly to workload changes:
- Neon’s autoscaler-agent fetches metrics from the virtual machine every 5 seconds to assess CPU load and overall memory usage.
- Memory usage within Postgres is checked every 100 milliseconds for granular monitoring.
- The autoscaler-agent analyzes the Local File Cache (LFC) every 20 seconds, evaluating working set sizes across time windows ranging from 1 to 60 minutes to ensure it remains in memory.
Get more information here.
How does Neon tackle pooled connections, and how is it different from Aurora Serverless v2?
Neon integrates PgBouncer directly into its architecture, enabling seamless transaction pooling with minimal setup. By appending “-pooler” to the connection string, Neon efficiently manages up to 10,000 concurrent connections, queuing requests during spikes instead of rejecting them. In contrast, Aurora Serverless v2 often struggles with connection pool exhaustion and slower scaling, especially during sudden traffic increases.
Neon’s built-in pooling works alongside its autoscaling, dynamically allocating resources when demand rises. This eliminates the need for external tools like RDS Proxy, reduces latency, and simplifies serverless database management, providing a smoother experience during high-traffic scenarios. Read more.
Are there differences in developer features?
Neon offers a smoother developer experience overall, but the standout feature is its ability to support database branching workflows for dev/test environments. With Neon’s copy-on-write branching, developers can instantly create isolated copies of a dataset without duplicating storage. This eliminates the operational burden of syncing data across multiple environments, allowing seamless testing and debugging. Branches are lightweight, cost-effective, and integrate easily with CI/CD pipelines, enabling a faster time-to-launch. Read a real-world example.
Can I see customer testimonials?
Neon is used by companies of all sizes, from small startups to larger teams. Here’s some testimonials:
“We had to overprovision Aurora to handle our spiky traffic, and even then, the writer database would get overwhelmed. We provision 10x more than we need on average to keep things running smoothly (Jonathan Reyes, Principal Engineer at Dispatch) – Read case study
“Neon is truly serverless. In some “serverless” databases, you still pay for reserved capacity, and that’s not very helpful if you want to use branch-based development. What you need is the ability to quickly spin up branches and test them in real production settings” (Robert Chandler, CTO at Wordware.ai) – Read case study
“Database branching is the best quality-of-life improvement to my tech stack that I can think of in recent years. Second to maybe only Copilot” (Miguel Hernandez, Backend Tech Lead at Neo.Tax) – Read case study
“Neon worked out of the box, handling hundreds of Lambdas without any of the connection issues we saw in Aurora Serverless v2. On top of that, Neon costs us 1/6 of what we were paying with AWS” (Cody Jenkins, Head of Engineering at Invenco) – Read case study
“Thanks to autoscaling, we no longer have to worry about performance during our openings or wasting time resizing instances” (Pieralberto Colombo, CTO at Recrowd) – Read case study
“Instead of having to overprovision our servers to handle peak loads, which leads to inefficiencies and higher costs, Neon’s autoscaling handles it. We get more performance when we need it” (Julian Benegas, CEO of BaseHub) – Read case study
“Neon perfectly meets our needs for a Postgres solution that scales with demand. We can push the boundaries of what’s possible in our projects without compromising efficiency or costs” (Technical Director at White Widget) – Read case study
✨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.