Supabase vs Railway vs Neon: pricing breakpoints and when each one bites

I've deployed production Postgres on all three. Supabase for two client projects, Railway for one, Neon for my own site and two smaller client apps. Each one has a sweet spot — and a pricing cliff where it stops making sense.

This isn't a feature comparison. There are plenty of those. This is the pricing math from real projects, with the gotchas I hit that the marketing pages don't mention.

The short version

Supabase: the bundle deal

Supabase gives you Postgres + Auth + Storage + Edge Functions + Realtime in one dashboard. If you need all of those, the value is exceptional. The Pro plan at $25/month covers a lot.

Where I've used it: Two client projects — a B2B SaaS with auth, file uploads, and real-time presence. Supabase was the right call because the alternative was stitching together Auth.js + S3 + a separate Postgres host + a WebSocket server. Supabase bundled all of it.

Where it gets expensive:

1. Connection limits. The free tier allows 60 direct connections. The Pro plan gives more, but connection pooling (via Supavisor) has its own limits. If you're running a Next.js app with serverless functions, each function invocation opens a connection. At 50 concurrent users, you can hit the pool ceiling. The fix is PgBouncer or Supavisor in transaction mode — but that means you can't use LISTEN/NOTIFY or prepared statements across transactions.

2. Storage bandwidth. Supabase Storage is convenient but not cheap at scale. Serving 100GB/month of file downloads on Pro costs more than putting the same files on Cloudflare R2. For one client, we moved file serving to R2 after the storage bill doubled in month 3.

3. Compute add-ons. If you outgrow the shared Postgres instance, dedicated compute starts at $50/month and goes up fast. A 4-core instance is $100/month — at that point you're in Railway/Render territory with less flexibility.

The lock-in question: If you're only using Supabase for Postgres, migration is easy — it's standard Postgres. If you're using Auth + Storage + RLS policies + Edge Functions, you've built on the platform. Migrating means replacing 4 services, not 1.

Supabase pricing breakpoints

Railway: the simple path

Railway is the closest thing to "just deploy it." You push code, Railway runs it. Postgres is a plugin — click to add, get a connection string.

Where I've used it: One client project — a Node.js API with Postgres that didn't need auth or storage bundling. Railway was the right call because the founder wanted simplicity: one dashboard, one bill, no vendor-specific APIs.

Where it gets expensive:

1. CPU-based billing. Railway charges by vCPU usage + memory + storage. For a Node.js API that idles most of the time, this is cheap ($5–$10/month). For a Postgres instance running analytical queries or background jobs, CPU usage spikes and so does the bill. One client's bill went from $12/month to $47/month after adding a nightly data aggregation job.

2. No serverless Postgres. Railway Postgres runs 24/7 on a provisioned instance. You're paying for uptime, not queries. For a low-traffic app that gets 100 requests/day, you're paying for a database that's idle 99% of the time. Neon's serverless model is cheaper for this use case.

3. Egress. Railway charges for egress after the included amount. If your API serves large payloads (reports, exports, media), egress costs add up. Not a problem for most SaaS apps, but worth checking if you're serving files.

The advantage: Zero lock-in. Railway doesn't wrap Postgres in a proprietary layer. Your connection string works with any Postgres client. Migration out is pg_dump and you're done.

Railway pricing breakpoints

Neon: the serverless bet

Neon is serverless Postgres. Your database scales to zero when idle and spins up on demand. You pay for compute-hours and storage, not for a running instance.

Where I've used it: My own portfolio site (this one) and two client apps with low-to-moderate traffic. Neon was the right call because these apps have spiky traffic patterns — quiet most of the day, then bursts during business hours or events.

Where it gets expensive:

1. Sustained concurrency. Neon's pricing is cheap when your database is idle or handling sporadic queries. But if you have a constant stream of queries (background workers, real-time dashboards, high-traffic APIs), compute-hours accumulate fast. The free tier gives 190 compute-hours/month. A database that's active 8 hours/day uses ~240 compute-hours — you're on a paid plan by the end of month 1.

2. Cold starts. When your database has been idle and a request comes in, there's a cold start delay. Typically 200–500ms for the first query. For a portfolio site, nobody notices. For a production API where P99 latency matters, cold starts at 3 AM when the first user wakes up are a real issue. You can keep the database warm with a cron ping, but then you're paying for compute-hours you don't need.

3. Branching is incredible, scaling is complex. Neon's killer feature is database branching — create a copy of your production database for testing in seconds, with copy-on-write so it uses minimal storage. This is genuinely transformative for development workflows. But the autoscaling model means your bill is less predictable than a fixed-price instance. For budgeting purposes, I always add a 30% buffer to estimated Neon costs.

The advantage for serverless apps: If you're on Vercel with serverless functions, Neon's @neondatabase/serverless driver uses WebSocket connections instead of TCP. This eliminates the connection pooling headache that plagues serverless Postgres. No PgBouncer needed. Each function invocation gets a connection, uses it, drops it. Clean.

Neon pricing breakpoints

When to pick what

Pick Supabase when:

• You need auth + storage + Postgres as a bundle
• You want Row Level Security without building your own middleware
• Your team is small and the all-in-one dashboard saves time

Pick Railway when:

• You want simple, predictable hosting
• You don't need auth or storage bundled with your database
• You value zero lock-in and standard Postgres
• You're running background jobs or workers alongside your app

Pick Neon when:

• Your app is serverless (Vercel, Cloudflare Workers)
• Traffic is spiky or low-traffic (scale to zero saves money)
• You want database branching for dev/test workflows
• You're comfortable with usage-based billing

My default for new projects

For client MVPs where the founder wants everything in one place: Supabase Pro ($25/month). It's not the cheapest, but it eliminates 3 decisions (auth provider, file storage, database host) and the dashboard is good enough for non-technical founders to check things.

For my own projects and technical clients who want simplicity: Neon Free → upgrade to Pro when compute-hours exceed the free tier. The serverless model fits Next.js on Vercel perfectly, and database branching makes schema migrations stress-free.

For projects that need background processing or have predictable, steady traffic: Railway. Simple billing, no surprises, easy to reason about.

Building something and not sure which hosting stack fits? Let's talk — I'll recommend based on your actual traffic pattern and budget, not the marketing page.