Weekly Stack #04 — Neon

Every week, we break down one tool from the stack that powers Kaiten — what it does, why we picked it, and how it fits into a unified SaaS architecture.

This issue is the Engineering Edition. We're going deep on the database layer.

Prefer the printable version? Download the PDF.

What is Neon?

Neon is Postgres rebuilt for the cloud. Not "Postgres in the cloud" (every provider does that). Not "managed Postgres" (that's RDS). Postgres rebuilt — meaning the storage layer, the compute layer, and the lifecycle have been redesigned from the ground up to behave like modern cloud infrastructure.

The result is a serverless Postgres that scales to zero when idle, branches like Git, and bills you by actual usage rather than by always-on instances.

If you've ever provisioned an RDS instance on the smallest tier "just to have a database for the staging environment" and watched it cost you $30/month for doing nothing, Neon is the response to that frustration.

Why We Picked Neon for Kaiten

We use Neon for both staging and production at Kaiten. Three reasons.

1. Decoupled compute and storage

Traditional Postgres ties compute and storage together. Your "database instance" is one thing — a server with a disk attached. If you want to scale compute, you scale storage too. If you want to spin up a copy for testing, you copy the entire disk.

Neon decouples them. Compute is stateless and ephemeral. Storage is persistent and lives in object storage (S3-style). This means compute can spin up on demand, scale to zero when idle, and be replicated cheaply for branching.

For a SaaS where workload patterns vary throughout the day, this maps to real cost savings — and to flexibility you don't have with RDS.

2. Database branching

This is the killer feature. You can branch a Neon database the same way you branch code in Git. Each branch starts from a snapshot of another, sharing storage until data diverges.

What this enables in practice:

• Preview databases per feature branch: every PR can have its own isolated copy of production data, ready in seconds, with zero impact on prod.
• Safe migration testing: run your migration on a branch, validate, kill the branch. No "did I just break staging?" anxiety.
• Instant staging refreshes: branch from prod, run for a day, throw away. Stop maintaining a dedicated staging DB that drifts from prod over time.

The mental model is the same as feature branching in Git. Once you've worked this way, going back to a shared staging database feels archaic.

3. The pricing model that fits early-stage SaaS

The free tier is generous. Postgres-compatible. Open-source extensions work. You can prototype, build a project, and get to first paying customers without thinking about database infrastructure cost.

For a founder, that's significant. The cost of database infrastructure used to be one of those "you need a budget before you can build" line items. With Neon, that's gone.

The Brutal Honesty: Our Free Tier Burns Out

Here's where I get to be honest about something most "Neon is great" articles skip.

At Kaiten, we run an event-driven architecture with Debezium capturing change data capture (CDC) events from our Postgres tables. This means there's always something listening on the database — even when no human is actively querying.

The result? Our compute endpoint never goes to zero. The whole point of Neon's "scale-to-zero" model is that idle databases stop costing money. But Debezium's persistent connection keeps the endpoint alive, even when CPU is at 0.5% and RAM is barely allocated.

Here's what that looks like in our Neon console (visible in the visual at the top of this issue): tiny spikes of activity, but the endpoint is continuously online. The CPU graph shows 0.05–0.25 compute units used, which is barely anything — but it's still allocated, still billed.

The math is simple. Even at the smallest compute size (0.25 CU = ~1GB RAM), running 24/7 burns through the free tier compute hours before the end of the month. We're not stressing the database. We're just keeping it awake.

The lesson: Neon's free tier is brilliant for traditional request-response workloads where idle time is real idle time. For event-driven architectures with persistent listeners (Debezium, NATS bridges, Kafka Connect, anything that holds an open connection), the free tier won't last. You'll need a paid plan from day one.

This isn't a Neon flaw — it's a workload mismatch. The marketing talks about "scale to zero." The reality is: you only scale to zero if nothing is listening. If you've architected an event-driven system, you've also architected something that keeps your compute alive.

I wish I'd known this before. I'm telling you so you don't have to learn it from a billing surprise.

A Bigger Picture: Where Neon Fits in the Future of Data Systems

Neon being acquired by Databricks in May 2025 wasn't a random acqui-hire. It was strategic.

I wrote a longer piece on this — From Lakehouse to Lakebase: Why Databricks Buying Neon Changes Everything — but the short version: Neon's architecture (decoupled compute/storage, scale-to-zero, branching) is exactly what Databricks needs to extend its Lakehouse from analytics into operational data.

The vision is Lakebase: a single data layer where Postgres transactions and Lakehouse analytics live on the same open foundation (Iceberg/Delta). Your app writes through Neon, the writes land in object storage, analytics and ML can query the same data instantly, and predictions can flow back into the app — no ETL pipeline, no data duplication.

For a SaaS founder, the implication is significant. Today, you start with a transactional database and bolt analytics on later. Tomorrow, with Lakebase, analytics is built-in from day zero. The database isn't the operational store anymore — it's part of a continuous feedback loop between operations and intelligence.

Picking Neon today isn't just picking a database. It's picking a position in the direction the data layer is headed.

Market Landscape

How does Neon compare to the alternatives?

Neon — Serverless, Branching, Open-Source. The right choice for SaaS teams who want elastic Postgres with developer-grade workflows.

Supabase — Postgres + Auth + Realtime + Storage. Bundled like Firebase. Strong if you want a full backend kit; less compelling if you only need the database layer.

PlanetScale — Serverless, but MySQL-based. Best-in-class branching too. The right choice if your stack is MySQL-native; not relevant if you've committed to Postgres.

AWS RDS / Aurora — The default in big-company stacks. Reliable, expensive, no scale-to-zero, no branching. Overkill for early-stage. Aurora Serverless v2 closes some of the gap but still doesn't match Neon's developer experience.

Fly Postgres / Railway / Render — Convenient managed Postgres for small projects. None offer branching or true scale-to-zero. Fine for hobby projects, limiting for SaaS at scale.

The Bottom Line

Neon is the right choice for most early-stage SaaS teams building on Postgres — provided you understand the workload pattern that fits the pricing model.

If your app is request-response (REST API, web traffic, batch jobs that run and stop), the free tier and the scale-to-zero model will save you real money. If your app is event-driven with persistent connections (CDC, message queues with DB sinks, real-time sync), expect to pay from day one — and budget accordingly.

The branching alone is worth the switch. Once you've worked with database branches per feature, going back to a shared staging database feels like editing files without version control.

This is Weekly Stack #04. Every week, we break down one tool from the Kaiten stack. Previously: Dub.co × Ngrok — the two utilities that make your work visible.