Supabase is an open-source backend-as-a-service that provides real-time databases, authentication, and API services. It enables developers to build and scale applications quickly without managing server infrastructure.
One recurring issue we ve been seeing with Supabase setups is not the database itself, but how credentials are managed across environments. The common pattern looks something like:
credentials stored in .env files or secrets managers
multiple environments (dev, staging, prod)
manual propagation or duplication across those environments
It works, but over time it seems easy for things to drift:
a key gets rotated in one environment but not others
a redeploy misses an env var
credentials get misconfigured during setup or migration
Reviewers mostly see Supabase as a fast, reliable way to get a real backend running without much infrastructure work. The most repeated praise is the all-in-one mix of Postgres, auth, storage, APIs, realtime features, and a clean dashboard, plus strong docs and easy framework integrations. Many highlight row-level security as a major advantage for multi-tenant apps and safer data access. Founders of Slashy and ClawSecure echo that speed and control. Main complaints are thinner docs in places, some auth and RLS learning curve, free-tier limits, and slower edge-function cold starts.
developer experience (31)authentication features (63)PostgreSQL integration (47)
Supabase holds NightMarquee's users, scans, credits and the public board, with about forty migrations so far, all plain SQL checked into the repo. Auth handles sign-in and I verify the claims on the server, so the app always knows who is asking. The part I use most is the one people talk about least: it is a normal Postgres, so the heavier jobs go through a direct connection and I have never had to fight an ORM. What could be better: the dashboard's SQL editor and the migration CLI still feel like two separate products, and I would like the migration history to be visible from the dashboard without leaving it.
fast performance (20)developer experience (31)easy setup (40)seamless integration (18)scalable infrastructure (36)authentication features (63)PostgreSQL integration (47)
Built a full marketplace as a solo founder on Supabase (auth, postgres, RLS, storage, edge functions, realtime, serverless webpages). I'd have needed a small backend team to wire all of that up myself. Postgres underneath means I'm never locked in and never fighting a custom DSL.
RLS in particular is the unlock, security policies live next to the data, not buried in middleware that drifts out of sync.
What needs improvement
limited free tier (2)
Edge function cold starts are still slower than I'd like for user-facing calls. The dashboard's SQL editor is good but loses your unsaved query if you accidentally navigate away, would love a draft auto-save,
Oh, and the pricing jump from Pro to Enterprise is steep for solo founders who outgrow the free tier but don't need a whole org plan yet a middle "indie" tier would be welcome.
Looked at Firebase (no SQL, vendor lock-in), Pocketbase (single binary is great but no managed scaling), and rolling my own on raw Postgres +Hasura + custom auth.
Supabase wins because it gives you real Postgres with the production wiring already done, but doesn't hide the database
behind an opinion. Migrations are SQL files. Queries are SQL.
If I ever leave, I leave with my data and schema intact
open source (27)easy setup (40)real-time capabilities (30)authentication features (63)PostgreSQL integration (47)
I used Supabase to build the backend for a subscription tracker app I launched recently, and two things stood out.
Row level security was the big one. I could enforce that each user only ever sees their own data at the database level, instead of trusting every query in my app code to filter correctly. That's a real security guarantee, not just a convenience.
Auth was the other win. Email and password plus Google OAuth were both straightforward to wire up, and the client libraries worked cleanly on both the server and client side in a Next.js app.
What needs improvement
The free tier's built-in email sending has a low rate limit, which I hit during testing before I connected my own SMTP provider. It makes sense as a limit, but it would help to see that called out more clearly upfront so new users don't discover it mid-project. Row level security is powerful, but writing policies correctly the first time took some trial and error. A few more worked examples for common patterns, like "a user can only see rows they own," would shorten that learning curve.
I looked at Firebase before settling on Supabase. Firebase felt easier to start with, but it's a NoSQL document store, and I wanted a real Postgres database with SQL and proper relational data. Row level security was the deciding factor: it gave me per-user data isolation enforced by the database itself, which Firebase's rules system can approximate but not in the same way.