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 other serverless databases.
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 other serverless databases
The Neon architecture is unique in the following ways:
- Neon compute costs are up to 80% cheaper vs other serverless databases.
- Neon provisions instances in < 1 s, compared to other serverless databases which can take up to 20 min.
- Neon uses transparent compute units, vs abstractions used in other serverless databases.
- 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 other serverless databases.
- Connection pooling is built-in in Neon, unlike some other serverless databases that require separate proxies.
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.