Postgres with the parts you would have built anyway
Auth, storage, realtime and row-level security on top of ordinary Postgres. It sits behind a Next.js or Node.js build, so the first month goes into the product rather than into plumbing every product needs.
Where Supabase earns its place.
Postgres underneath
No proprietary query language. It is a database you could move elsewhere without a rewrite.
Access rules next to the data
Row-level security, so permissions live in one place instead of scattered through the application.
Auth and storage included
Sign-in, sessions and file handling on day one, not in month two.
Pairs with Next.js and Node.js
The client libraries are first class in both, so the same access rules hold on the server and in the browser.
Why this, and when not.
Why we choose it
It removes a month of undifferentiated work and leaves a database you still own at the end of it.
When we would not
A WordPress site. That runs on MySQL already, and a second database beside it buys nothing. Self-hosted, one stack is also one set of users and one schema, so several small products are better served by plain Postgres.
Services built on Supabase.
Building a product back end?
A 45-minute technical call with the engineer who would lead the build. You leave with a scope sketch either way.