How I Run 7 Postgres Databases for $0 on Neon

The Night I Counted My Databases and Panicked for No Reason

It was late 2024. I was about to spin up database number four — or was it five? — for yet another side project I’d definitely abandon in a month. And out of nowhere, this cold little thought hit me: how much am I paying for all these?

I’m Indian and I’m paranoid, so this is the kind of thing that keeps me up. I opened my Neon dashboard, braced for a number, and started counting. Clickly’s database. A forms thing I never launched. An uptime-monitor idea. A staging clone of something. A “learning” project. My blog’s little store of data. Seven of them, blinking away in the console.

Total monthly bill: zero. Not “almost nothing.” Not “a couple of dollars.” Actual, literal $0.

My first reaction wasn’t relief. It was suspicion. Nobody gives you seven PostgreSQL databases for free — I’d been quoted more than that for a single box on AWS RDS years ago, back when I still thought AWS was where serious people hosted things. So I did what any broken engineer does. I went and read the pricing page line by line, convinced there was a trap. There wasn’t a trap. There was just a mechanism nobody had explained to me properly. This post is me explaining it to you.

---

Why I Have Seven Databases in the First Place

Let’s get the embarrassing part out of the way: I have seven databases because I have a graveyard of half-finished products.

If you’ve read the advanced database rabbit hole, you know I started Clickly, a Bitly-style URL shortener, in 2023, and over-engineered it into the ground. But Clickly wasn’t the only one. Every time an idea grabbed me at 1 AM, the first thing I’d do — before a single line of product code — was create a database. It’s a reflex. A SaaS without a database isn’t a SaaS; it’s a landing page.

So the databases pile up. And here’s the thing most people get wrong: they cram all of that into one big database to “save money,” then spend a weekend untangling schemas when they finally want to shut one project down. I do the opposite. Every project gets its own database, fully isolated. Clickly’s data never touches the forms app. When a project dies, I delete its database and there’s nothing to clean up. GDPR-friendly, blast-radius-friendly, brain-friendly.

The reason I can afford to be that clean is entirely down to how Neon’s free tier is structured. That’s the actual secret.

---

The Trick: Neon Counts Per Project, Not Per Account

Here’s the one sentence that makes this whole thing work:

On Neon’s free plan, the storage and compute limits are counted per project, not per account.

Read that twice, because it flips everything. Most free tiers give you one bucket — X gigabytes, Y hours, split across everything you run. Neon gives every project its own bucket, and lets you have up to 100 projects on the free plan.

So a “database” in my world is really a Neon project: one project, one Postgres database, one isolated allowance. Seven projects means I get seven separate free allowances stacked up. It’s not that Neon is being reckless — it’s that their architecture separates storage from compute, so a sleeping project genuinely costs them close to nothing to keep around. They pass that saving straight to you.

This is also the honest correction to something I wrote in the survival guide — back then the free tier was far stingier, basically one project. Neon has quietly made it more generous since, not less, which almost never happens with a free tier. In October 2025 they even doubled the free compute allowance. So if anything, “run seven databases for free” is easier to justify today than when I first said it.

One caveat so you don’t shoot yourself in the foot: this only works if you use one project per database. If you create a single project and stuff seven databases inside it, they all share that one 0.5 GB / 100-CU-hour allowance and you’ll blow through it. Seven projects, one database each. That’s the layout.

---

The Free Tier, Line by Line (2026)

I hate vague “generous free tier!” claims, so here are the actual numbers I verified on Neon’s pricing page, per project:

What	Free plan (per project)	What it means for you
Storage	0.5 GB	Enough for tens of thousands of rows of real data
Compute	100 CU-hours / month	~400 hours at 0.25 CU — more than a side project uses
Autoscaling	Up to 2 CU (8 GB RAM)	Handles a genuine traffic spike
Branches	10 per project	Dev/staging branches off prod, like Git
Scale-to-zero	After 5 min idle	The reason the bill is $0 (more below)
Egress	5 GB / month	Data leaving Neon — the one shared limit to watch
Projects	100 per account	You will not hit this

Half a gig sounds small until you remember what Postgres actually stores. Text, IDs, timestamps, JSON — it compresses beautifully. My Clickly database, with hundreds of thousands of fake link records I generated while stress-testing, sat comfortably under the limit. Unless you’re storing images in the database (please don’t — that’s what Bunny storage is for), 0.5 GB per project is a lot of runway.

And 100 CU-hours is the part people underestimate. A side project with real-but-modest traffic, autoscaled down to a quarter of a compute unit, runs for roughly 400 hours a month on that. Combine it with the next feature and you basically never run out.

---

Scale-to-Zero: The Feature That Makes $0 Possible

This is the single most important thing to understand about Neon, and it’s why the whole “seven databases” thing isn’t a gimmick.

Traditional Postgres — RDS, a VPS, whatever — bills you for a server that’s running, whether anyone’s using it or not. Your database at 4 AM on a Tuesday with zero traffic still costs the same as your database at peak. That’s insane for a solopreneur whose side project gets eleven visitors a week, three of whom are me checking it still works.

Neon separates storage from compute. When a project sees no queries for 5 minutes, the compute suspends to zero. The storage stays (it’s cheap and always there), but you stop burning compute hours entirely. The next time a query comes in, the compute wakes back up.

So my seven databases aren’t seven servers humming 24/7. They’re seven sleepy little things that wake up only when I poke them, use a sliver of my 100 free hours, and go back to sleep. A dead project that nobody visits costs me nothing, forever, and I don’t have to remember to shut it down. On the free plan you can’t even turn scale-to-zero off — which sounds like a limitation but is exactly what keeps the bill at $0.

---

The Catches Nobody Puts on the Landing Page

I’m not here to sell you Neon. I’m here so you don’t get burned. Here’s what scale-to-zero and the free tier will actually cost you in comfort:

Cold starts. When a suspended project wakes up, there’s a lag — usually under a second, but it’s there. For a background job or a hobby dashboard, who cares. For a user staring at a login button, that first-query delay after an idle spell can feel janky. If a project ever gets real users, this is the first reason you’ll want to move it off scale-to-zero (which means paying).

Connection handling. Serverless functions on Vercel or a backend on Railway can open a flood of database connections and exhaust Postgres fast. Use Neon’s pooled connection string (the one with -pooler in the host), not the direct one. If you’re on Prisma, its cold-start behavior fights serverless a little; Drizzle has been smoother for me on serverless. Small detail, saves you a confusing afternoon.

Egress is the sneaky one. 5 GB of data leaving Neon per month is plenty for normal app traffic — but unlike storage and compute, this allowance isn’t stacked per project, so it’s the one shared ceiling across your account. Pull whole tables down repeatedly (a badly-written cron job, an analytics export loop) and you’ll hit it. This is the limit I’d actually watch, not storage.

The 0.5 GB ceiling is real. It’s a hard cutoff, not a soft throttle. Hit it and writes start failing until you clean up or upgrade. For a side project that’s fine. For anything storing user-generated content at volume, budget to outgrow it.

None of these are dealbreakers for what the free tier is for: side projects, prototypes, and SaaS ideas that haven’t earned a rupee yet. They’re just the fine print I wish someone had handed me.

---

When You’ll Actually Have to Pay

Here’s the good news buried in the bad: the day you outgrow the free tier is the day a project started working. That’s a problem you want.

When one of my seven databases finally needs to stay always-on (no cold starts) or blows past 0.5 GB, I move that one project — and only that one — onto Neon’s Launch plan. It’s pay-as-you-go now, with no monthly minimum: you’re billed for what you actually use, roughly $0.106 per CU-hour of compute and $0.35 per GB-month of storage, with a much larger egress allowance. The other six stay on free. That’s the beauty of one-project-per-database — you upgrade surgically, not all-or-nothing.

People ask why I don’t just use Supabase, which bundles auth and storage and a dozen other things out of the box. No shade — they’re funded, they’re good, and for a non-engineer who wants batteries included, they’re a great call. But I’m an optimization-obsessed engineer who’d rather assemble exactly the pieces I need and keep the bill legible. Neon does one thing — serverless Postgres — better than anyone, and I bolt the rest on myself. (If you want the full head-to-head on where the dollars go, I tallied what it really costs to run a SaaS line by line.)

One more thing worth knowing, purely because it’s wild: Neon got acquired by Databricks for around a billion dollars in 2025, and Databricks’ CEO said something like 80% of the databases on Neon were being spun up automatically by AI agents, not humans. Which tells you exactly why the free tier is built to let you create a hundred projects with a keystroke. The world moved to disposable, on-demand databases while most of us were still nursing one precious server. Might as well take advantage.

---

The Bottom Line

Seven databases. Zero dollars. And the whole thing comes down to one architectural decision on Neon’s part — separating storage from compute so an idle database is nearly free — and one on mine: never sharing a database between projects, so each one draws from its own free bucket.

I over-engineered my way to this, of course. I benchmarked databases for three weeks for a URL shortener nobody uses. But the scar tissue is worth something: I now spin up a real, isolated, production-grade Postgres database for a new idea in about thirty seconds, and it costs me nothing until the idea proves it deserves my money. That’s not a hack. That’s just knowing where the free lunch actually is. (When it’s time to put a backend in front of these databases, here’s where I actually deploy without a surprise bill.)

This is the Broken Engineer Guide — I over-engineer everything, fail at business, and hand you the shortcut so you skip the scars. Go build something. Just give it its own database.