Neon on Kilter: How the Tiers Map, What It Costs, and What's Coming

Who this is for: engineers who like Neon's serverless Postgres and its branching model, and want to know — precisely — how it maps onto Kilter, what the equivalent workload costs, and where the two philosophies actually diverge.

Neon and Kilter answer different questions. Neon asks "how do I make one Postgres cheap, serverless, and branchable?" Kilter asks "how do I compose a whole application — database, auth, storage, search, workflows — and own the result?" The single-sentence contrast that the rest of this playbook unpacks:

Neon branches the data. Kilter branches the environment.

Neon's tiers, at a glance

The numbers below are read straight off Neon's plan comparison (as of writing — Neon iterates on pricing, so treat the dollar figures as the current shape, not a contract).

Two things drive everything on this page. First, the unit of billing is the CU (compute unit) — one vCPU plus 4 GB of RAM — metered by the hour and scaled to zero when idle. Second, compliance and networking (SOC 2, HIPAA, VPC, IP allow-listing) only exist on Scale, which roughly doubles the compute rate.

Mapping a CU onto Kilter's rate card

Kilter doesn't have a "CU." It renders everything to plain Kubernetes with real resource requests, and meters the underlying resources at the published rate card: $0.012 / vCPU-hr, $0.005 / GB-hr of memory, $0.08 / GB-month of storage, $0.01 / GB egress.

So a Neon CU — 1 vCPU + 4 GB — has an exact Kilter equivalent:

1 CU  =  1 vCPU + 4 GB RAM
      =  (1 × $0.012)  +  (4 × $0.005)
      =  $0.012 + $0.020
      =  $0.032 per CU-equivalent hour

Line the three up:

Containers vs branches — the core mental model

This is where the two models genuinely part ways, and it's worth being precise rather than glib.

A Neon branch is a copy-on-write clone of your database — data plus schema — created in seconds, billed only for the divergence, scaled to zero when nobody's querying it. It is the best thing about Neon. A PR gets its own branch off production data; a migration gets tested against a real copy; you throw it away when you merge.

A Kilter environment is a copy of your whole stack. kilter deploy --env pr-247 stands up an isolated namespace — its own app pods, its own Postgres, its own Ory, its own storage — with its own hostname and a default-deny network policy. Broader than a branch (the entire application, not just the DB), and heavier (real pods, not copy-on-write pages).

If your mental model is "I want a throwaway copy of prod data," Neon's branch is purpose-built and Kilter's environment is heavier than you need — for now. If your model is "I want a throwaway copy of the whole application," Kilter's environment does in one command what you'd otherwise assemble from Neon + Supabase + Vercel previews.

Pricing a small/medium app — the Likeable model

Here's the exercise the pricing page implies but doesn't spell out: take a real small/medium app, set sensible included limits, and price the overage against Neon.

The workload. One always-on Postgres autoscaling around 0.75 CU with scale-to-zero overnight (~550 CU-hours/month), 15 GB of storage, 60 GB egress. A normal SaaS side of things — not a toy, not a unicorn.

Illustrative Likeable ($20/mo) allocation. To make the comparison concrete, say the Likeable tier includes 750 CU-hours of compute, 25 GB storage, and 100 GB egress per month across your apps, with anything above billed at the rate card. (Illustrative limits — the binding allocation lives in your portal.)

Now scale the app past the allocation. Add 400 CU-hours and 20 GB storage:

• Neon Launch adds 400 × $0.106 + 20 × $0.35 = +$49.40/mo.
• Kilter adds 400 × $0.032 + 20 × $0.08 = +$14.40/mo — same rate card, no tier jump, no category games.

And if you need SOC 2 or HIPAA, Neon moves you to Scale (~$69 base, $0.222/CU-hr) — the compute line alone on our workload becomes 550 × $0.222 = $122/mo. On Kilter those controls are a platform property of your own cluster, not a pricing tier that doubles your compute rate.

The hobbyist with 15 projects: Neon vs Supabase

This is the scenario that explains Neon's whole design — and it's worth being honest about where Neon simply wins.

A hobbyist has 15 side projects. Most are idle most of the time.

• On Neon: the Free plan allows up to 100 projects, each scaling to zero after 5 minutes idle, sharing 100 compute-hours/month. Fifteen mostly-idle projects wake on demand, sleep otherwise, and cost $0. This is why hobbyists love Neon: idle projects are free because they aren't running.
• On Supabase: the Free plan caps you at 2 active projects — the rest pause after a week and there's no true scale-to-zero on paid. To keep 15 projects live you're on Pro (~$25/mo) plus a dedicated compute instance for each additional project (~$10/mo on the smallest), landing around ~$165/mo for the same 15 projects that cost nothing on Neon.

So the hobbyist ends up on Neon for one reason: scale-to-zero + a high project cap turns fifteen idle databases into a near-zero bill, while Supabase charges per always-on project.

Where does Kilter fit? Honestly: if all you want is 15 disposable idle Postgres instances, Neon Free at $0 is unbeatable and you should use it. Kilter plays a different game — every one of those 15 "projects" is a full-stack app you own (DB + auth + storage + jobs), that also scales to zero when idle via KEDA:

• Community (free): 10 scale-to-zero apps — for building in the open.
• k8gentic Engineering ($100/mo): 15 scale-to-zero apps + production-lite + a full production app.

Fifteen real projects — each needing a database, login, file uploads, and a background job — cost $100/mo on Kilter as sovereign full-stack apps, versus stitching Neon + Supabase + a host per project and still not owning the result. For throwaway DBs, Neon. For fifteen things you actually intend to ship, Kilter.

The full-stack comparison

Neon is Postgres-first (now growing Auth and a Data API). Supabase is the batteries-included BaaS. Kilter is the composable, self-owned stack.

The pattern: Neon is deepest on the one thing it does; Supabase is broad and managed-on-their-terms; Kilter trades a little managed convenience for owning the whole stack, running it locally with real parity, and deploying it to infrastructure you control.

What Kilter can't do yet — but is building

Being straight about this is the whole trust model. Neon has real, shipped features that Kilter does not have today:

The recipe: coming from Neon

If the trade lands for you, replacing a Neon-backed app is short:

1. Scaffold. kilter init my-app.
2. Add the database — and the rest of what your app actually needs: kilter add postgres (with pgvector if you're doing embeddings), then ory, garage, typesense, temporal as required.
3. Bring your schema. Point your existing migrations at the provisioned Postgres; kilter db migrate runs them.
4. Local parity. kilter up runs the whole stack on the same images prod runs — a green light locally is a real signal.
5. Branch the environment. kilter deploy --env pr-123 for a full-stack preview — the Kilter analog to a Neon branch, one namespace per PR.
6. Ship. kilter deploy --bootstrap provisions, migrates, and blocks until healthy. You land in production, Org Only.
7. Go live. Hit Promote to open external access.