Supabase Developer for Next.js, Postgres & RLS

What I build with Supabase

I build the whole product, not just the database layer: a Next.js App Router front end, a Postgres schema designed for how the business actually reads its data, row level security enforcing tenancy at the database rather than in your components, and billing that survives contact with real customers. When the product is multi-sided, that schema is the marketplace — sellers, roles, commissions — not a single-tenant SaaS table with an extra flag.

• Postgres schema design — tables, relations, constraints, and indexes designed around your real query patterns, with migrations checked into the repo rather than clicked into a dashboard.
• Multi-tenancy — org_id (or equivalent) on every tenant-owned table, foreign keys that can't cross tenants, and RLS policies that make a leaked client query a no-op instead of a data breach.
• Row level security (RLS) — tenant isolation enforced in Postgres, so a bug in a React component can't leak another customer's rows. Written with tests, not hope.
• Auth — email, OAuth, and magic links, plus the parts people skip: role claims, server-side session validation, and service-role keys that never reach the browser.
• Realtime & storage — subscriptions where they earn their keep, signed upload URLs, and access rules that match your RLS policies instead of contradicting them.
• Stripe billing — subscriptions or marketplace payouts wired to your Supabase data with idempotent webhooks. Splitting payments is Stripe Connect; the full multi-sided product is marketplace development.
• Migrations — off localStorage prototypes, Firebase/Firestore, or a schema that was never designed for tenancy. Incremental dual-writes, not a weekend cutover.
• Edge Functions & background jobs — scheduled work, queues, and third-party syncs that don't fall over when an API returns a 429.

Row level security is where most Supabase projects go wrong

The single most common problem I'm called in to fix is RLS that was switched on late, or switched off to unblock a deadline and never switched back. Supabase makes the happy path so fast that teams ship a working app before anyone has written a tenancy model — and retrofitting one across dozens of tables and policies is far more expensive than designing it on day one.

The specific traps are consistent: policies that call auth.uid() inside a subquery on every row and quietly destroy query performance at scale; using the service-role key in a route handler "just for this one query", which bypasses RLS entirely; and policies for select with nothing equivalent for insert, update, or delete. I design the tenancy model first, write policies per operation, and add tests that assert one tenant cannot read another's rows.

If your app would still work with row level security turned off, you don't have row level security — you have a suggestion.

Multi-tenancy that Postgres actually enforces

A SaaS MVP on Next.js and Supabase fails in a predictable way: the first paying team works, the second team can see the first team's rows. That's not a Supabase bug. It's a missing tenancy model — no org_id on the tables that need it, RLS policies that check auth.uid() but not membership, and a service-role bypass in a route handler that was supposed to be temporary.

I design tenancy as a Postgres constraint, not a React convention. Every tenant-owned table carries the org key, membership lives in a table the policies can join, and tests assert that tenant A cannot select, insert, update, or delete tenant B's data. That's the difference between a full-stack app you can sell and a prototype you have to rewrite when the second customer signs.

Migrating off localStorage or Firebase

Two common origins for a Supabase project: a Next.js prototype that stored state in localStorage (or a JSON blob) until it needed auth and a second user, and a Firebase/Firestore app whose document model started fighting joins, reporting, or the bill. I treat both as migrations, not greenfield.

From localStorage: extract the real entities, put them in Postgres with constraints, then put RLS on before the first extra user. From Firebase: dual-write, backfill, verify parity, cut reads over one surface at a time — the same sequence I describe on the Firebase developer page and in Firestore pricing at scale. The expensive version is a weekend dump-and-hope.

Supabase or Firebase? An honest answer

Choose Supabase when your data is relational and you need real queries — joins, aggregates, transactions, and constraints the database enforces for you. Choose Firebase when you want document-shaped data, deep mobile SDK support, and you're comfortable denormalising to keep reads cheap.

In practice most B2B SaaS is relational, which is why I default to Postgres. The costs also behave differently: Firestore bills per document read, so your bill scales with traffic patterns in ways that are hard to predict — I broke that down with real numbers in Firestore pricing at scale. Supabase bills for compute and storage, which is easier to forecast but means you own query performance. Neither is universally right, and I'll say so if your project suits the other one.

Proof, not promises

Database Vault is my own SaaS, built on Next.js and Supabase — auth, billing, scheduled backup orchestration, encrypted storage, and one-click restore across PostgreSQL, MySQL, MongoDB, Firebase, and Supabase. It's a product I run, so I've dealt with the unglamorous parts: migrations against live data, background jobs that must not double-run, and support tickets when they do.

That work sits alongside AI SaaS and AI agent platforms, and it extends the same App Router stack I describe on the Next.js development services and Next.js SaaS pages.

How we'd start

Send me your schema — or a description of what the product does if there isn't one yet — plus where it hurts. I'll tell you whether it's a data model problem, an RLS problem, or a performance problem before quoting anything, because those are three very different jobs.

New builds usually start with a scoped v1: schema, RLS, auth, one core workflow, and billing. Rescue work starts with an audit. Either way, send me the details and you'll get a straight answer about scope and sequence.