Supabase vs Self-Hosted PostgreSQL: What I'd Choose and Why

Supabase is Postgres under the hood, which means the "Supabase vs self-hosted Postgres" question isn't really a database question — it's a question about who you want operating that database, and what you get bundled alongside it.

What Supabase actually gives you beyond "managed Postgres"

Auth, storage, realtime subscriptions, and row-level-security-based authorization patterns, all wired to the same Postgres instance and reachable through a generated client. For a small team, that bundle replaces what would otherwise be several separate services (an auth provider, an object storage service, a websocket layer) — the value isn't just "someone else runs the database," it's "several adjacent problems are pre-solved and integrated."

What self-hosted Postgres actually gives you

Full control over configuration, extensions, and cost structure at scale — and no dependency on a specific provider's roadmap or pricing changes. You're also fully responsible for backups, failover, connection pooling, and being the person who gets paged when the database has an issue at 3am, unless you're paying a different managed provider (RDS, Cloud SQL) for exactly that operational layer minus Supabase's bundled extras.

Where I'd choose Supabase

Early-stage projects and small teams where engineering time is the scarcest resource, and where the bundled auth/storage/realtime genuinely replace services you'd otherwise have to integrate and maintain separately. The operational simplicity is worth more than the control you're giving up, at that stage.

Where I'd choose self-hosted (or a different managed provider)

Projects with specific compliance or data-residency requirements Supabase's infrastructure doesn't meet, projects at a scale where Supabase's pricing model stops making sense compared to running your own, or teams that already have the operational maturity (and staff) to run Postgres well and want full control over extensions and tuning.

The thing people get wrong in this comparison

Treating it as "Supabase vs Postgres," as if they're different databases with different guarantees. They're not — the actual comparison is "do I want the bundled auth/storage/realtime layer and the operational hand-off that comes with it, or do I want to own and integrate those pieces myself." Framing it that way makes the decision about your team's actual constraints, not about database feature comparisons that don't really apply.

Takeaway

Both are Postgres. The real question is whether you want Supabase's bundled, managed convenience or the control (and operational burden) of running it yourself — and that's a team-capacity and project-stage question, not a technical one.