Supabase

Operator's take

Most no-code and low-code builders hit the same ceiling: their native database works great until it doesn't. You start needing row-level permissions, real-time updates across users, or a place to run a bit of custom logic — and suddenly you're bolting on three extra services to cover gaps that should have been solved at the data layer. Supabase's bet is to make Postgres the foundation and ship everything else around it rather than asking you to assemble the stack yourself.

What that means in practice: you open a project, get a full Postgres instance (with a visual table editor if you want it), and immediately have auto-generated REST and GraphQL endpoints based on your schema. Auth with social logins and row-level security is built in. Realtime subscriptions use native Postgres change feeds, so collaborative features don't require a separate WebSocket service. Edge Functions cover custom business logic or webhook handling without standing up a server. And pgvector is included, so if you're building anything that touches AI — semantic search, embedding storage, RAG pipelines — you can do it in the same database rather than spinning up a separate vector store.

The honest tradeoff: Supabase is SQL-shaped through and through. If you're comfortable with relational thinking and want a proper backend without managing infrastructure, it punches way above its price point. If your team doesn't know SQL and doesn't want to learn, or if your data model is fundamentally document-shaped, you'll spend more time fighting the tool than using it.

What it's good at

• Complete backend in one project — database, auth, storage, APIs, realtime, and serverless functions all connected out of the box; no assembly required.
• Auto-generated APIs from schema — REST endpoints appear automatically when you create tables, with optional GraphQL via pg_graphql; useful for wiring a frontend before you have any backend code.
• Row-level security and auth built in — user management with social logins, JWT-based sessions, and fine-grained table-level permissions without standing up a separate auth service.
• Real-time subscriptions via Postgres — collaborative and live-updating UI features over native change feeds; simpler than managing a separate pub/sub layer.
• Vector search with pgvector — store and query embeddings directly in Postgres alongside your relational data; one less external service for AI-powered features.
• Generous free tier with a clear path up — free tier covers most hobby and early-stage projects; paid plans unlock higher limits without forcing you to re-architect anything.

What it's not

• Not a no-code tool — there's a visual table editor, but the real surface area is SQL, client libraries, and code; non-technical teammates won't self-serve here.
• Not flexible on the database engine — Postgres-only; if you need a document store, graph database, or NoSQL flexibility, you're in the wrong place.
• Not cost-predictable at scale — storage, edge function invocations, and egress all meter separately on paid plans; a spike in usage can produce a surprising bill.
• Not the right fit for pure no-code stacks — tools like Airtable or Xano exist to put data management in non-developer hands; Supabase assumes someone on the team reads SQL and can wire client libraries.