What Neon is, in plain language
Neon is a managed PostgreSQL service. You get a normal PostgreSQL database that your application connects to with an ordinary connection string, but Neon runs the servers, storage, and backups for you. If you already know how to write SQL, nothing about your queries changes.
The part that surprises people new to Neon is how it is built internally. Neon separates storage from compute. Your data lives in a storage layer that grows independently, while the thing that actually runs your queries — the compute endpoint — starts, stops, and resizes on its own. That separation is why a Neon bill has two very different kinds of numbers on it.
- Project — the top-level container Neon creates for you. A project holds branches, databases, and compute endpoints, and it is the unit DatabaseMeter tracks as one entry in your portfolio.
- Branch — a copy-on-write copy of your data, similar in spirit to a Git branch. Branches are cheap to create, which is why teams use them for staging and preview environments.
- Compute endpoint — the PostgreSQL process that executes your queries. It can scale up under load and scale to zero when idle.
- Compute unit (CU) — Neon's sizing unit for that endpoint, roughly a bundle of vCPU and RAM. One CU running for one hour is one CU-hour.
Why CU-hours confuse new users
Storage is measured by how much data you keep. Compute is measured by how long a compute endpoint stays awake and how large it is while awake. Those are multiplied together, which means a small database that never sleeps can cost more compute than a much larger database that is only queried during business hours.
This catches novices off guard because the instinct is to assume the bill follows the data. It usually follows the clock. A single background job that pings the database every thirty seconds can hold compute open around the clock, and the resulting CU-hours look identical to genuine heavy traffic on the invoice.
If you want to see the arithmetic before you change anything, the Neon CU-hour calculator lets you try different compute sizes and awake hours without connecting an account.
Scale to zero, cold starts, and the tradeoff nobody explains
Scale to zero means Neon suspends the compute endpoint after a period with no activity. You stop accruing compute charges during that idle window. The tradeoff is a cold start: the first query after suspension waits while the endpoint resumes.
For a hobby project or an internal tool, that pause is usually fine and the savings are real. For a customer-facing API where the first request of the morning must feel instant, it may not be. Neither choice is wrong — but you should make it deliberately rather than discovering it from a support ticket or an invoice.
The practical question is what is actually keeping compute awake. Health-check pings, connection pools that never idle out, cron jobs, ORM keep-alives, and monitoring agents are the usual suspects. When you attach optional read-only PostgreSQL telemetry to a Neon project, DatabaseMeter can flag sustained low-but-nonzero activity that fits this pattern. It is a heuristic, not proof, and it is labeled that way.
What to watch each week
Monitoring is only useful if it changes a decision. For a small Neon footprint, four signals cover most of what matters, and none of them require you to become a database administrator.
- Database size and its trend. A number by itself means little. A number that doubled in three weeks is a question worth answering — see why a PostgreSQL database keeps growing.
- CU-hours per project. Compare the projects you consider important with the ones you forgot about. Abandoned preview branches are a common source of quiet spend.
- Idle-looking activity. Very low but continuous query volume often points at a keep-alive rather than a user.
- Sudden changes in pace. A step change in growth or compute usually maps to a deploy, a new feature, a retry loop, or a data import.
How DatabaseMeter reads Neon data
DatabaseMeter connects with a Neon API key you create yourself, scoped as narrowly as Neon allows. The key is validated on the server, encrypted before it is stored, and never displayed again after you save it. Collection is read-only: DatabaseMeter discovers your projects and reads metadata and available consumption history. It does not create, resize, suspend, or delete anything in your Neon account.
Just as important is what DatabaseMeter refuses to do. When Neon does not expose a value, that metric is shown as unavailable instead of being estimated, inferred from a different metric, or quietly displayed as zero. A blank you can trust is more useful than a number you cannot. Neon's own console and invoice remain the authoritative source for billing.
If you also run databases on other platforms, the provider capability matrix shows exactly which metrics are available where, and Neon vs Supabase compares the two usage models side by side.