Scale With Traffic
Neon scales up and down automatically, matching your workload. Get performance when you need it.
TL;DR
Many applications have variable traffic, i.e. compute requirements fluctuate. This is a common source of "bill bloating" in managed databases; if this is you, you're probably provisioning a larger machine to accommodate these traffic spikes. Neon saves you the trouble:
- Databases autoscale up and down automatically according to load.
- You pay only for the compute you use, without downtime or manual work.
- You only pay for active databases: your dev/test instances automatically pause when idle.
Neon is serverless Postgres. We have a generous 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.
Variable traffic, fixed costs?
Many applications have variable traffic patterns:
A productivity application might have increased demand during working hours as teams collaborate and complete tasks.
An AI analytics startup could face heavy processing loads during off-peak hours when batch data jobs are run.
A gaming platform might experience surges in user activity during evenings when players are most active.
Online shops might see spikes when certain sales are run… And so on.
Variable load patterns are common, but traditional managed databases require provisioning a fixed amount of CPU and memory. To avoid degraded performance or even outages, it is standard practice to provision for peak traffic, which means paying for peak capacity 24/7 — even though it's needed only a fraction of the time.
Pay only for what you use with Neon
Neon solves this inefficiency via a serverless architecture. By natively separating storage and compute, Neon implements two features that allows you to pay only for the compute you use without investing any manual work: autoscaling and scale to zero.
Neon adjusts CPU and memory up and down automatically.
Costs are controlled by setting a max autoscaling limit
You get a performance boost when you need it.
No manual resizes or downtimes. Neon scales up and down smoothly and immediately.
Non-prod databases scale to zero when inactive. Instead of paying for compute 24/7, you skim the costs of your supporting databases to a minimum.
Transparency with open-source architecture. Explore our code in GitHub.
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.
Why Neon vs Aurora Serverless
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.
How much money are you wasting on unused compute?
Example deployment in RDS
- 1 production database (db.r6g.8xlarge)Runs 24/7
- Dev databases (db.t4g.micro)Used interminently
- Test databases (db.t3.medium)Used interminently
Input parameters
Deployment
Number of test databases
Number of dev databases
Usage
How many hrs/day are test databases running?
How many hrs/day are dev databases running?
How many hrs/ day do you hit peak traffic?
Dollars overpaid
Bill that could be saved
With scale to zero and autoscaling
