Supabase vs Self-Hosted Postgres: When to Choose Which in 2026

Supabase ate the "Postgres + auth + storage + realtime" market from 2021 onward by being radically easier than the alternatives. In 2026 that ease still matters, but the trade-offs around self-hosting Supabase, or skipping the bundle entirely and assembling your own Postgres-centric stack, have changed enough to be worth re-litigating.

This is the framework we actually use when teams ask us "should we stay on hosted Supabase?"

The three real options#

There aren't two options; there are three. Mixing the first two up is where most of the confusion in this debate comes from.

1. Managed Supabase, supabase.com hosts your database, your auth, your storage, your edge functions. You hit the dashboard; they handle the boxes.
2. Self-hosted Supabase, you run the open-source Supabase stack (GoTrue, PostgREST, Storage, Realtime, Studio, Kong) on your own infrastructure. Same APIs as managed; you operate the boxes.
3. DIY Postgres + assembled stack, managed Postgres (Neon, RDS, Crunchy, Fly Postgres) plus pieces you pick yourself for auth (Clerk, Auth.js, your own table), storage (S3, R2), and so on. No Supabase code anywhere.

Managed Supabase, end of 2025 reality#

For 90% of new SaaS projects, this is still the right starting point. The 2025 platform improvements were significant: branching databases for preview environments, much better connection pooling via Supavisor, a real free-tier replacement (the "Compute Add-on" model), and proper read replicas. The DX is hard to beat.

You should stay on managed Supabase as long as:

• You're happy paying per-project compute past the free tier.
• You can live with the (improving) cold-start latency on Edge Functions.
• You don't need a VPC-private database or single-tenant infrastructure.
• Your data residency constraints fit the regions Supabase offers.
• You don't need to install extensions outside their allow-list.

You start to outgrow it when:

• Connection counts spike during traffic bursts and Supavisor transaction-mode pooling stops being enough.
• You need to install custom extensions like pg_partman for very large time-series tables, or replication tooling not in their allow-list.
• You need on-prem or a specific compliance posture (HIPAA, certain government baselines, India's DPDPA "significant data fiduciary" regime).
• Your monthly bill clears five figures and the equivalent on managed-Postgres + DIY would be roughly half.

Self-hosted Supabase#

The middle path. You get the same client SDKs, the same PostgREST API shape, the same RLS story, but the database and services run on your infrastructure. The Supabase Docker bundle is what most teams use. Coolify, Railway, and Fly each have one-click recipes.

Worth doing when:

• You need to keep data in a specific region, on specific hardware, or inside a VPC that managed Supabase can't peer into.
• Your traffic is high enough that the per-project pricing on hosted starts to look silly compared to the cost of a beefy VM and a managed Postgres backing it.
• You want to extend the stack: custom GoTrue identity providers, additional Postgres extensions, alternative storage backends.

The honest downsides:

• You own the on-call. Upgrades, security patches, backups, monitoring are now yours.
• The realtime service is the trickiest piece to operate at scale - it's a separate Elixir app with its own quirks.
• Studio (the admin UI) is the Supabase product's weak point when you self-host. It assumes you have a single-tenant project and its multi-environment story isn't great. (This is the gap Suparbase exists to fill, but we're biased.)

DIY Postgres + a stack#

The third path is: just Postgres, plus the auth/storage you actually want, with none of Supabase's stack on top. In 2026 this is more viable than ever because:

• Neon's branching, autoscaling, and bottomless storage make it a near-drop-in for Supabase's database half.
• Clerk and Auth.js are both mature enough to replace GoTrue for most shapes of app, including B2B tenants and SSO.
• R2 / S3 + a small signing proxy gives you Supabase Storage's API with a 90% smaller surface area.
• You skip PostgREST entirely and write your own server. With Next.js route handlers, Drizzle, and tRPC or oRPC, the "write your own BFF" pattern is unrecognisable from where it was in 2020.

// Postgres via Drizzle, auth via Clerk, storage via R2.
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";
import { auth } from "@clerk/nextjs/server";

const sql = postgres(process.env.DATABASE_URL!, { max: 10, prepare: false });
const db = drizzle(sql);

export async function listMyPosts() {
  const { userId } = auth();
  if (!userId) return [];
  return db.execute(
    `SELECT id, title, status FROM posts WHERE author_id = ${userId}
     ORDER BY created_at DESC LIMIT 50`,
  );
}

The trade-off: you wrote that endpoint, including its auth check, instead of letting RLS handle it. For a small team that doesn't already speak Postgres fluently, the "RLS handles authorization at the database" story Supabase ships is a meaningful win. For a team that's already writing servers anyway, the integration tax of Supabase's opinions can outweigh the win.

Decision matrix#

We don't do scorecards because they hide the relative weights. But as a rough heat-map:

• You're a single-developer side project → managed Supabase. Free tier, two clicks, done.
• You're a B2B SaaS, < $5k/mo Postgres bill → managed Supabase. The dev velocity from RLS + the bundled services beats the cost.
• You're B2B SaaS, $5k-$50k/mo Postgres bill → honest conversation about self-hosted Supabase vs DIY. Often the right answer is "migrate the database to Neon or RDS, keep GoTrue + PostgREST on a small VM for now, plan to replace those over 12 months".
• You're an agency operating 20+ client projects → managed Supabase per client, with a centralised admin tool (this is exactly the pattern we built for).
• You're building consumer apps with millions of users → DIY. The bundled services break first under load; you'll end up replacing them piecewise anyway.
• You have a heavy compliance posture → self-hosted Supabase, or DIY with a managed-Postgres provider that has the certifications you need.

Migration paths between them#

None of these decisions are permanent.

Managed → Self-hosted Supabase

This is the easiest direction. pg_dump the database, restore into your own Postgres, point a fresh Supabase Docker bundle at it, replicate your auth users via the GoTrue admin API. Plan a couple of hours of downtime; do it on a Saturday.

Managed → DIY Postgres

The expensive migration. You need to replace GoTrue (Auth.js or Clerk can import auth.users with some effort), replace Storage (R2 + a signing function), and replace PostgREST (write a backend). Budget weeks, not days. The savings are real if you're large enough that the percentage matters.

Self-hosted Supabase → Managed Supabase

Less common but plausible. You'll bring your auth users via the same admin API; your storage objects need to be reuploaded. Database is a pg_dump away.

What we actually do#

Suparbase ourselves is a Next.js app talking to Postgres (Neon for production, Postgres-in-a-Docker for local dev) with NextAuth handling sessions. We don't run any Supabase services for our own product because we don't need them, the whole point of the product is to operate other people's Supabase projects.

We send our customers to managed Supabase nine times out of ten. It's where ~80% of the apps we admin live. The other ~20% are self-hosted Supabase (regulated industries) or pure-Postgres (high-scale apps that outgrew the bundle). All three shapes work fine with our workspace: the only thing it needs is a PostgREST endpoint and a key.

The choice that matters most isn't Supabase vs DIY. It's whether you build a tooling layer around your database that you trust. Once that's in place, the underlying host is a swappable detail.