Your quote says Supabase, so most of the backend is bought rather than built

It's a Postgres database with the usual chores already done

Underneath all of it is PostgreSQL, a relational database that's been around since the nineties and runs a large share of the software you already use. Supabase didn't invent a database. It hosts one for you, one per project, and wraps the parts every application needs around it.

Those parts are the actual product. User accounts and login. Somewhere to put uploaded files. An API generated from your tables, so adding a column makes it available without anyone writing an endpoint. A live channel that pushes changes to open browsers. Short server-side functions for work a visitor's device can't do.

None of it is exotic. It's the list a team would otherwise build before the first feature anybody asked for.

Why it's shaped the way it is

Supabase started in 2020 with a stated target: be the open-source answer to Firebase. That explains most of what follows.

Firebase, Google's bundle of the same parts, made small teams fast by removing the backend entirely. It keeps data as documents rather than tables, which suits some products well, and it's Google's to run either way. Supabase copied the convenience and changed the foundation. Relational tables, because most business data really is rows and relationships, and code you can run on your own servers.

If your data is document-shaped and renting doesn't bother you, the older answer is still a reasonable one.

What it's genuinely good at

Speed, for a team with nobody spare. Two or three developers can have accounts, permissions, file uploads and a self-updating screen running in days rather than a quarter, and none of them has to become the infrastructure person. That's the strongest argument on the table.

The second one is quieter and lasts longer. Your data sits in Postgres, the format the whole industry already knows. Standard SQL, standard backups, standard tools. Your reporting person can query it, and a database dump is a portable copy rather than an export in somebody's private shape.

Postgres brings its extensions along too, so full-text search, geographic queries and the vector search behind AI features sit in the database you already have. The dashboard is legible to people who don't write code, which sounds minor until a customer first disputes what happened.

Where it stops

The first ceiling has nothing to do with performance. Because the browser talks to the database directly, the only thing between one customer's records and another's is a set of Row Level Security rules somebody wrote. Postgres enforces them properly. The open question is whether they were written, switched on, and tested by someone actively trying to get past them.

Then there's the shape of the work. Anything long-running sits awkwardly: a long nightly job, a video to process, a queue that has to survive a restart. The server-side functions are built for short requests, so that work ends up somewhere else. Cheaper to decide where at the start.

Two more belong to Postgres rather than to Supabase. It caps how many things can connect at once, so a lot of short-lived functions in front of it need a pooler in between, which the platform provides. And analytics queries against the database that also serves customers work right up until they don't. A bundle that keeps the database out of sight makes both easier to forget.

The data leaves. Everything around it doesn't.

This is the honest version of the portability argument, because the marketing version overstates it.

What genuinely moves is the database. Tables, rows, relationships, and your user records, which sit in that same database rather than in a separate identity product. A standard dump gets all of it, and any Postgres host will take it. That's the best single reason to prefer this over a closed equivalent.

What doesn't move is everything wrapped around it. The login flows, the file permissions, the generated API your code is written against, the live channels, the functions. Rewriting those is the actual migration. Running the open-source version yourself softens it, at the price of operating several services instead of subscribing to one.

So you'd keep your data and rebuild your plumbing. Better than most platforms leave you. Not nothing.

Who has to be around after launch

Supabase is a developer tool with a friendly dashboard, not a no-code product. That decides who you need on hand.

Somebody, in-house or on retainer, has to be comfortable with SQL and with the access rules. Not full time, and not an infrastructure team, because patching, backups and certificates belong to the vendor on the hosted service. The schema and the rules are yours, and they change every time a feature does.

Before the platform question, settle the ownership one. Whose account is this in, who writes the access rules, and who gets called when a query goes slow. Those three names tell you more about year two than the platform choice ever will.