Build And Ship
The question worth asking about any backend is not what it can do. It is what leaving costs.
Supabase is a hosted Postgres database with authentication, file storage and row level security wired in. It is not a proprietary datastore with a database bolted on the side. You get a real Postgres instance and a standard connection string, which means the exit path is a database dump rather than a rewrite.
Lock in is not a feature list. It is the cost of the door.
That is why it sits under both of the products I build in house. Wise STR holds the property record. Wise Media OS runs proposals, clients and delivery. Both are Postgres underneath, and both could move.
What is Supabase, exactly?
Postgres, plus the parts every application needs and nobody enjoys building. Authentication with sessions and providers. File storage with access rules. Auto generated APIs over your tables. Realtime subscriptions when you want them.
The important word is plus. The database is not an implementation detail hidden behind an abstraction layer. It is the product, and everything else is assembled around it. You can open a SQL editor and write a query. You can attach any Postgres tool you already know how to use.
Row level security is the feature and the footgun
Row level security is Postgres deciding, per row, whether the current user is allowed to see it. Supabase leans on it hard, because the generated API exposes tables directly to the client. The policy is the security boundary.
Done properly this is excellent. The rule lives next to the data instead of scattered through application code, and it holds no matter which client is asking.
Done carelessly it is the single most common way a Supabase project leaks. A table with row level security disabled sitting behind a public API is an open table. Not a subtle misconfiguration. An open table.
The default that ships fastest and the default that ships safely are rarely the same default.
The discipline is simple and not negotiable: row level security on, every table, from the first migration. Write the policy when you create the table, not before launch, because before launch never actually arrives.
Why it sits under both in house products
Because both are boring data problems wearing different clothes. A property record and a client record are the same shape underneath: rows with owners, permissions, history and files attached.
Supabase covers the identical eighty percent for both, which means the interesting work goes into what each product actually does rather than into building authentication twice. That is the only real argument for a backend platform, and it is a good one.
Both are wired to the rest of the stack through self hosted n8n, which is what moves a record from one into the other. It also buys one mental model. When something misbehaves at 1am the debugging path is the same in both systems, and that is worth more than any individual feature on the comparison page.
When would you not use it?
When the data is not relational. If the shape is genuinely document oriented, or the workload is analytical at serious scale, Postgres is the wrong tool and Supabase inherits that.
And when you need to run somewhere Supabase does not. Self hosting is possible, but it is a meaningfully different operation from using the hosted product, and pretending otherwise is how teams end up maintaining infrastructure they never budgeted for.
What breaks?
Connection limits. Serverless functions open connections aggressively and Postgres has a ceiling. The answer is the connection pooler, and the reason it catches people is that everything works perfectly in development, where there is exactly one of you.
Migrations that only exist in the dashboard. It is easy to change a schema by clicking, and it is a trap. If a change is not in a migration file in version control, it does not exist on any other environment and it will not survive a rebuild.
The third is cost drift on storage and bandwidth rather than on the database itself. Verify current pricing tiers directly, and watch the egress line rather than the row count.
Every backend looks cheap until the second environment.
Common questions
Is Supabase a good choice for production?
Yes, when the data is relational and row level security is applied from the first migration. Because it is standard Postgres underneath, the operational knowledge, the tooling and the exit path are all conventional rather than proprietary.
Does Supabase lock you in?
Less than most backend platforms. The database is standard Postgres and can be dumped and restored elsewhere. The authentication and storage layers are the parts that carry real migration effort, not the data itself.
What is row level security in Supabase?
A Postgres feature that decides, per row, whether the current user may access it. Because Supabase exposes tables through a generated API, these policies are the security boundary, and a table without them is effectively public.
Supabase or Firebase?
Supabase is relational Postgres, Firebase is document oriented. Choose on the shape of your data. If your records have clear relationships and you want to write SQL, Supabase fits. If they do not, it does not.
Can you self host Supabase?
Yes, but it is a materially different operation from using the hosted product and should be budgeted as infrastructure work rather than assumed to be a configuration change.
Choose the backend you could leave. You probably never will, and that is exactly what keeps it honest.
