Neon’s free tier is generous, but understanding its nuances is key to avoiding unexpected charges or service interruptions.
Let’s see what that looks like in practice. Imagine you’re spinning up a new project and want to test out Neon’s serverless Postgres. You create a new Neon project, and by default, it comes with a free tier configuration.
Here’s a peek at a typical neonctl configuration for a free tier project (though you’d usually interact with this via the UI or API, this shows the underlying settings):
{
"compute": {
"quota_bytes": 0,
"min_scale": 0,
"max_scale": 1,
"period_sec": 60,
"warm_period_sec": 300,
"autoscaling": true
},
"storage": {
"quota_bytes": 5368709120,
"period_sec": 2592000
},
"branches": {
"quota_count": 5,
"period_sec": 2592000
},
"connections": {
"max_concurrent_requests": 1000,
"max_connection_pool_size": 100
}
}
This JSON snippet reveals the core of the free tier. You get a certain amount of resources, and once you hit those limits, you either scale up to paid tiers or face restrictions.
The primary problem this solves is providing a zero-cost entry point for developers to experiment with and even deploy small-scale applications on a robust, managed Postgres platform. You get the full power of Postgres, including features like branching and serverless scaling, without an upfront financial commitment.
Internally, Neon manages compute resources dynamically. When your database receives a query, Neon’s platform wakes up a compute instance (if it’s not already warm). If there are no queries for a warm_period_sec (e.g., 300 seconds or 5 minutes), the instance is suspended to save resources. This is the "serverless" magic. The min_scale and max_scale parameters dictate how many compute instances can be active at any given time. For the free tier, min_scale is typically 0, and max_scale is 1, meaning only one compute instance can be running at a time. quota_bytes for compute is 0, indicating that active compute time isn’t metered in the free tier; rather, it’s the idle time that matters.
Storage is where you’ll see a hard limit. The storage.quota_bytes of 5368709120 translates to 5 GiB of data. This includes your primary branch and any other branches you create. storage.period_sec of 2592000 is 30 days, meaning this quota resets or is evaluated monthly. If you exceed 5 GiB, you’ll be prompted to upgrade.
Branching is another key feature with a limit. branches.quota_count of 5 means you can have up to 5 active branches (including the main branch) in your free tier project. Each branch consumes storage, so creating many branches can quickly eat into your 5 GiB storage limit.
Connection limits are also in play. connections.max_concurrent_requests at 1000 means your application can have up to 1000 requests being processed by Postgres simultaneously. connections.max_connection_pool_size of 100 is the default pool size for the compute instance, ensuring efficient connection management. These are generally quite generous for typical free-tier use cases.
Here’s the part that often trips people up: Neon’s free tier compute is billed by active usage, but capped by a generosity limit. While the compute.quota_bytes is 0, implying no direct charge for compute time, there’s an implicit limit on how much active compute time you can consume before Neon nudges you towards a paid plan. This isn’t a direct byte-hour charge like traditional cloud VMs, but rather a system-wide resource allocation. If your project is consistently active and demanding compute resources beyond a certain threshold (which isn’t explicitly published but is understood to be substantial for free tier), you might be asked to upgrade to ensure fair usage for all. The warm_period_sec is crucial here; keeping your database active without much idle time will consume more of this implicit compute allowance.
Once you’ve mastered the free tier limits, you’ll likely want to explore how to optimize your database performance for a serverless environment.