Scale With Traffic
Neon scales CPU and memory automatically to match your app
TL;DR
If your app has variable traffic, here's how Neon can save you time and money:
- Databases autoscale. CPU and memory scale up and down automatically. When you see traffic spikes, your database provisions more compute automatically; when traffic dies, it scales down.
- You pay only for the compute you use. No downtime, no manual work.
We have a Free Plan - Get started here
Our database traffic peaks at nights and on weekends. Building on a database that preemptively autoscales allows us to regularly handle these traffic spikes.
Fixed Compute = Manual Resizes, Extra Costs
Variable load patterns are common, but traditional managed databases require provisioning a fixed amount of CPU and memory.
To avoid performance issues during traffic spikes, you’re likely provisioning a larger machine than you need most of the time. Scaling up must be done manually. Scaling down may require downtime.
Neon Autoscaling Fixes This Problem
Neon is serverless Postgres. Instead of provisioning a fixed CPU/memory, you specify an autoscaling range.
Your database will autoscale up and down automatically between those limits, matching your app’s traffic.
Autoscaling is nearly instantaneous, without downtime. Read about our autoscaling algorithm and how it compares to Aurora’s.
When we were using MySQL in Azure, we had to manually upgrade the database during the days of peak traffic and downgrade later in the day, which caused a couple of minutes of downtime and a huge waste of time for the team.
Neon vs Aurora Serverless v2
The Neon architecture is inspired in Amazon Aurora, but with some key differences:
- Neon compute costs are up to 80% cheaper vs Aurora Serverless v2.
- Neon provisions instances in < 1 s, compared to Aurora's up to 20 min.
- Neon uses transparent compute units, vs the ACU abstraction in Aurora Serverless.
- Neon supports database branching with data and schema via copy-on-write, improving development workflows.
- Neon's read replicas don't require storage redundancy, differently than Aurora's.
- Connection pooling is built-in in Neon, vs Aurora's RDS Proxy.
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.