Supabase

Here’s the moment that changed how I think about building software.

I needed a quick prototype for a client pitch: a simple app with user authentication, a database, file uploads, and an API. The traditional approach — spin up a server, install a framework, configure a database, set up an ORM, build auth from scratch, configure S3, write all the endpoints, deploy. Two to three days of setup before writing a single line of application logic.

With Supabase, I had all of that running in under 30 minutes. A real PostgreSQL database with a visual editor. Authentication with email, Google, GitHub, and magic links — working, with sessions and JWTs. File storage with access controls. Auto-generated REST and GraphQL APIs for every table I created. Real-time subscriptions so the UI updates instantly when data changes.

I showed up to the client pitch with a working prototype. They’d expected a slide deck.

Supabase is what happens when someone looks at Firebase (Google’s backend-as-a-service) and asks “what if this was built on Postgres instead of a proprietary NoSQL database, and what if it was open source?” The answer is a tool that’s become the default backend for AI-era prototypes, indie products, and increasingly, production applications with real traffic.

What Supabase is

A backend-as-a-service built on PostgreSQL. It bundles everything you need for a web or mobile application backend:

Database — a full PostgreSQL instance. Not simplified, not proprietary. Full SQL support, extensions, foreign keys, indexes, views, functions, triggers. You get a visual table editor in the dashboard and direct SQL access.

Authentication — sign-up and login with email/password, magic links, phone/SMS, and social providers (Google, GitHub, Apple, and more). Handles sessions, JWTs, and refresh tokens automatically.

Storage — file storage with access controls, image transformations, and an S3-compatible API.

Auto-generated APIs — the moment you create a table, Supabase generates RESTful and GraphQL APIs for it. No code, no configuration. You can immediately query, insert, update, and delete data.

Realtime — subscribe to database changes over WebSockets. When a row changes, connected clients are notified instantly. This is how you build live dashboards, collaborative features, and chat.

Edge Functions — serverless TypeScript functions for custom business logic, webhooks, and third-party API calls.

Vector embeddings — store and query AI embeddings using pgvector, right alongside your regular data. Build semantic search, recommendation engines, and RAG systems without a separate vector database.

All open source. Client libraries for JavaScript, React, Vue, Next.js, Flutter, Swift, and Kotlin.

Why Supabase matters now

Two things drove the explosion in 2025-2026.

First, AI coding tools need databases. When Claude, v0, or any AI tool generates a full-stack application, the AI needs somewhere to store data and authenticate users. Supabase became the default because its APIs are simple enough for AI to generate correct code on the first try. Auto-generated REST endpoints mean the AI doesn’t need to write backend routes.

Second, pgvector turned Postgres into an AI database. Every AI application doing semantic search or RAG needs vector storage. Instead of running Pinecone as a separate service, Supabase stores embeddings right next to your regular data. One query can join your user table with a similarity search. No separate service, no data synchronization, no additional bill.

Supabase also ships an MCP server — meaning Claude Code can directly create tables, manage data, and run migrations from the terminal.

Row Level Security

This is Supabase’s approach to authorization, and it’s fundamentally different from how most backends handle permissions.

Instead of writing authorization logic in your API code (“if user.role === admin, allow access”), you write security policies directly on the database tables. The database itself enforces who can read, insert, update, and delete which rows. Regardless of how someone accesses the data — through the REST API, GraphQL, or a client library — the policy is enforced.

Why this matters in practice: we had a client project where a frontend bug accidentally removed a user filter from an API call. In a traditional setup, that bug would have exposed every user’s data to every other user. With RLS, the query returned empty because the database policy caught what the application code missed. The bug was still a bug, but it was harmless instead of a data breach. That experience convinced me RLS isn’t a nice-to-have. It’s the reason I recommend Supabase over hand-rolled backends for most projects.

Authentication

Supabase Auth handles the entire user lifecycle — sign up, sign in, sessions, password resets, social logins, and token management. Enable Google or GitHub login in the dashboard, paste in your OAuth credentials, and it works. Magic links (passwordless login via email) are surprisingly popular for consumer apps where password friction kills conversion.

The connection to RLS is what makes it powerful: the authenticated user’s identity flows automatically into database policies. Sign in → Supabase issues a JWT → client includes it in every request → database applies RLS based on who you are. All automatic.

Storage, Realtime, and Edge Functions

Storage is built on S3-compatible object storage with a permissions layer. Upload files, serve them from a CDN, control access with the same RLS-style policies as the database. Image transformations (resize, crop, format conversion) happen on the fly via URL parameters.

Realtime lets you subscribe to database changes over WebSockets. New messages in a chat appear instantly. Dashboard metrics update without page refresh. Multiple users see each other’s changes in collaborative tools. No polling.

Edge Functions are serverless TypeScript functions running globally on Deno. Use them for custom business logic that doesn’t fit in a database query — webhooks, third-party API calls, scheduled jobs.

Pricing

Free tier: two projects, 500 MB database storage, 50K monthly active users, 1 GB file storage. Projects pause after 7 days of inactivity. Fine for learning and prototyping. Not for production.

Pro ($25/month): 8 GB storage, 100K MAU, no pausing, daily backups. This is the production baseline. Most small applications run $35-75/month with overages.

The cost that surprises people: compute is separate from the plan fee. The $25 includes a $10 compute credit. If you need a dedicated instance for production (and most apps do), that’s an additional $100/month. We learned this on our second Supabase project. The client saw “$25/month” and budgeted accordingly. Actual bill with dedicated compute, storage overages, and bandwidth: closer to $180/month. Not expensive, but triple what they expected. Now I walk clients through the full cost stack before building.

Team ($599/month) adds SOC 2, priority support, SSO, and audit logs. Enterprise adds HIPAA compliance, dedicated infrastructure, and custom SLAs.

Supabase vs Firebase

The comparison everyone asks about. Choose Supabase if you want SQL and relational data, data portability, open source, self-hosting as an option, or vector storage for AI. Choose Firebase if you need deep Google ecosystem integration, more mature mobile SDKs, or prefer NoSQL document structures.

The practical difference: Supabase is PostgreSQL with services layered on top. Firebase is a proprietary NoSQL database with services on top. For the AI builder’s stack, Supabase wins because pgvector, SQL joins, and RLS are all critical features Firebase doesn’t offer the same way.

What Supabase can’t do

Long-running background jobs (use Render or a dedicated worker). Complex server-side rendering (use Next.js on Vercel). Heavy compute like ML inference (use dedicated infrastructure). Email delivery (use Resend, SendGrid, or AWS SES).

The typical architecture: Supabase for database + auth + storage + Realtime, paired with Vercel for the frontend and optionally Render for backend workers.

The bottom line

Supabase eliminates the “backend tax” that has historically slowed every project. Database, auth, storage, APIs, realtime, and vector search — all provisioned in minutes, all managed, all accessible through clean client libraries.

For non-technical founders: you can have a real, production-grade backend without hiring a backend developer for the initial build. For engineers: it’s real Postgres underneath. You can write raw SQL, use any extension, connect with any client, and take your data anywhere.

Start a free project. Create a table. Enable auth. See how fast you go from nothing to a working backend. That speed is what makes Supabase essential in the AI builder’s stack.

---

This is the free web edition of Chapter 9. The full text — with Supabase setup scripts, RLS policy patterns, schema examples, Edge Function templates, and pgvector integration walkthroughs — is available in 42: The AI Builder’s Stack, coming Q3 2026 on Amazon in hardcover, paperback, and digital.