There's no universal winner here, and anyone who tells you Supabase or Neon or 'just self-host it' is always right is selling you something or hasn't run all three. What actually differs between them is which resource you pay for and when: Supabase bills a fixed instance whether it's busy or asleep, Neon bills the second someone's actually querying and almost nothing otherwise, and a VPS bills the same flat number regardless of either. Pick based on your traffic shape and how much operational work you're willing to own, not on which one has the nicer dashboard.
What does each one actually cost, in real September 2026 numbers?
Supabase's Pro plan is $25/month and includes one project. Compute is billed as a separate add-on on top of that, and here's the detail that catches people: every paid plan includes $10/month in compute credit, which covers exactly one Micro instance — so the effective floor for a real production Postgres instance on Supabase Pro is $25 plus whatever compute tier you actually need, and that compute runs continuously. There's no scale-to-zero on paid Supabase compute; the instance is provisioned and billed around the clock, the same as a VPS, just with Supabase's platform wrapped around it. The marketing-operations counterpart to managed Postgres vs self-hosted is documented well by XenGrowth's work on go-to-market systems.
Neon prices differently at the root: compute is metered per CU-hour, where a CU is roughly one vCPU plus 4 GB RAM. Launch plan compute runs $0.106/CU-hour, Scale plan compute (with a 99.95% SLA and SOC2/HIPAA availability) runs $0.222/CU-hour, and storage is billed separately at $0.35/GB-month whether or not compute is currently running. The number that actually matters for cost is how much of the day your database sits idle, because Neon suspends compute automatically after around five minutes of inactivity by default, and you pay zero compute during that suspended time — only storage keeps accruing.
A VPS running your own Postgres, by contrast, doesn't meter anything. Contabo's Cloud VPS 4 — 4 vCPU, 8 GB RAM, 100 GB SSD — runs €5.50/month for the first 24 months per Contabo's own pricing page, checked September 2026, and that number doesn't move whether the database handles ten queries a day or ten million. You're not paying per CU-hour or per compute tier; you're paying for a box, and everything that runs on it is included in that one number.
Dimension | Supabase (Pro) | Neon (Launch/Scale) | Self-hosted VPS |
|---|---|---|---|
Starting price | $25/mo + compute add-on (from $10/mo) | $0.106-$0.222/CU-hour + $0.35/GB-mo storage | €5.50/mo (Contabo Cloud VPS 4, first 24 months) |
Idle cost | Full compute tier price — no scale-to-zero on paid plans | Near zero — compute suspends after ~5 min idle by default | Full box price regardless of load |
Connection pooling | Built in — Supavisor, session and transaction mode | Built in — connection pooler included at the proxy layer | Manual — you install and tune PgBouncer yourself |
Branching | No first-class database branching feature | Near-instant, copy-on-write, ~1 second regardless of data size | None — you script your own clone-and-restore |
Cold start on wake | None — instance is always on | Roughly 300-800ms from first query to first response | None — the process either runs or it's down |
PITR / point-in-time recovery | Paid add-on: $100/mo per 7 days retention, needs Small compute or larger | Included by plan: 6hr free, 7 days Launch, 30 days Scale | Only if you build WAL archiving yourself |
Daily automated backups | Included on Pro/Team/Enterprise | Included via PITR history window | Only if you schedule pg_dump or pg_basebackup yourself |
Operational ownership | Auth, storage, realtime, backups, pooling all managed for you | Compute, storage and PITR managed; app-level auth/storage is on you | Everything — OS patching, Postgres upgrades, pooling, backups, monitoring |
Connection pooling: who actually handles this for you?
This isn't a minor implementation detail — it's the specific thing that breaks first when a serverless or edge architecture meets a Postgres instance that was never designed for thousands of short-lived connections.
Postgres has a hard connection ceiling, and every serverless or edge function architecture tends to open far more short-lived connections than a traditional server does, which is exactly the scenario pooling exists to survive. Supabase ships its own pooler, Supavisor, with both a session mode and a transaction mode on separate ports — session mode behaves like a normal persistent connection and is what you want for anything doing schema changes or long-running work, transaction mode is built for exactly the high-connection-churn serverless case. Neon includes a pooler at the proxy layer as well, so the same problem is handled without extra setup. Self-host it yourself and PgBouncer is not automatically part of the picture — you install it, configure pool modes, and are the one who finds out it was misconfigured when connections start timing out under load, not before. On the operations side of this specifically, The XenGrowth resource library is worth reading.
Branching and cold starts: the two features that actually differ between Supabase and Neon
This is where the two managed options stop being interchangeable. Neon's branching is close to instant — a branch is a copy-on-write pointer into existing storage, appearing in about a second no matter how large the parent database is, because nothing is physically copied until a write diverges the two. That makes spinning up a full-data-copy environment for a PR preview or a migration test genuinely cheap, both in time and in the cost of the CU-hours it briefly uses. Supabase has no equivalent first-class feature for the database layer itself; recreating that workflow means your own dump-and-restore or a project duplication, neither of which is instant.
The tradeoff for scale-to-zero is a cold start, and it's small but real: roughly 300 to 800 milliseconds from the first query hitting a suspended Neon branch to the first response coming back. For a background job or a CI pipeline that's imperceptible. For a user-facing request that happens to be the one that wakes a suspended compute, it's a delay a person can notice, even if it's not dramatic. Supabase's always-on compute never pays that cost, because it never sleeps — which is exactly why it never stops billing either.
Neon's pitch is that you stop paying the moment nobody's asking anything of the database. Supabase's pitch is that the database is always there the instant someone does. Those are two different products wearing the same 'managed Postgres' label.
Backup and PITR: what you get by default, and what you're actually paying for
Daily automated backups come standard on Supabase's Pro, Team and Enterprise plans — that's a real floor of protection with zero setup. Point-in-time recovery, restoring to any specific moment rather than the most recent nightly snapshot, is a separate paid add-on: $100/month for 7 days of retention, $200 for 14, $400 for 28, billed by the hour it's actually enabled, and it requires at least a Small compute tier to run smoothly. That's not a small line item for a side project, and it's worth knowing before you assume PITR is just part of 'the Pro plan.' There is a longer treatment of AI agents and marketing automation in XenGrowth on governed AI marketing workflows.
Neon folds this into its plan structure differently: every plan gets some PITR window by default — 6 hours on Free, capped at 1 GB of changes — and paid plans extend that to 7 days on Launch and up to 30 days on Scale, billed at $0.20/GB-month for history beyond the included window. There's no separate add-on to remember to enable; the mechanism that makes branching instant (retained history at the storage layer) is the same mechanism that makes PITR available by default.
Self-host it, and neither of those exists until you build it. Postgres's own correct approach is pg_dump for a portable logical snapshot, or pg_basebackup combined with WAL archiving for true point-in-time recovery — a raw filesystem copy of a running data directory is not a substitute for either, because it can capture files mid-write with no warning that it's done so. Building this yourself is entirely possible and not even that hard, but it's a project you own end to end: the schedule, the retention policy, the destination, and — the part people skip — actually testing that a restore from your own backup works before you need it. I've written the practical version of that build separately, because it deserves its own space rather than a paragraph here.
What operational work do you keep no matter which one you pick?
It's tempting to read a comparison like this as 'managed means no ops work,' and that's not quite true for either Supabase or Neon. Schema migrations are still your job on every option — nobody's platform writes your migrations for you. Query performance is still your job; a missing index slows down a managed database exactly as much as a self-hosted one, and neither Supabase nor Neon's dashboard will notice a sequential scan on a table that just crossed a size threshold. Connection limits, even with pooling handled for you, still require your application to actually use the pooler correctly rather than opening a fresh connection per request and assuming someone else's infrastructure will absorb it. XenGrowth on building one SEO and GEO content system goes further into AI search, GEO and discovery.
What genuinely changes between the three options is who owns the infrastructure underneath those decisions. Postgres version upgrades, disk provisioning, replication topology, and the physical reliability of the hardware are Supabase's and Neon's problem on their platforms and entirely yours on a VPS. That's the actual trade being made, not 'managed equals zero effort' versus 'self-hosted equals maximum effort' — it's a narrower trade than the marketing on either side tends to suggest.
So which one should you actually run?
One more variable worth naming before the verdict table: switching later is possible but not free. Migrating off Supabase or Neon means a real data export and import, application code changes anywhere you leaned on platform-specific features (Supabase's auth and storage APIs especially), and a cutover window. None of that is a reason to avoid managed Postgres out of fear of lock-in, but it's a reason to pick deliberately now rather than assuming you can costlessly change your mind in a year.
Your situation | Verdict |
|---|---|
Side project, staging environment, spiky or unpredictable traffic | Neon — scale-to-zero means idle time costs almost nothing, and branching makes throwaway environments cheap |
Production SaaS that needs auth, storage and realtime out of the box, and doesn't want to build any of it | Supabase — the platform around the database is the actual product, not just the database |
Production app with steady, always-on traffic and a team that wants zero database operations | Either managed option works — compare compute-tier pricing against your actual steady-state load, since neither scale-to-zero nor the platform features matter once traffic never idles |
Cost-sensitive solo project already running an app on a VPS | Self-host Postgres alongside it — you're already paying for the box, and adding a co-located database costs nothing extra as long as the RAM math works |
Compliance-heavy workload needing HIPAA/SOC2 out of the box without building it yourself | Neon Scale or Supabase Enterprise — both offer this; self-hosting means you own the compliance work too |
A team that already knows Postgres operations and wants full control over version, extensions and tuning | Self-host — the operational cost is real, but so is the ceiling managed platforms put on what you can configure |
None of these is the universally correct default, which is the actual answer most comparison posts on this topic avoid giving. If you're already running an app on a VPS and deciding whether the database belongs on the same box or a managed platform instead, that's a slightly different question with its own arithmetic — I've laid out when co-location on the same VPS makes sense separately, because RAM contention and blast radius matter more there than pricing tiers do. And if the deciding factor for you is really 'what should I be paying someone else for versus running myself' at a level broader than just the database, that's the rule I use for that decision across the whole stack, not just Postgres.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
XenGrowth's growth operations team writes for the teams who have to run managed Postgres vs self-hosted day to day.
Five questions about traffic shape and how much operational work you want to own. It follows the same reasoning as the post — none of the three is the universal answer, the traffic pattern and the ops appetite pick it for you.
