Supabase

The decision that separates a serious setup from a toy is whether you run Supabase locally as well as in the cloud. Install the CLI and link it to your project. This gives you a local Postgres stack you can break and reset freely, and it makes your schema a set of versioned migration files in your repo rather than clicks in a web UI that no one can audit later. I treat the cloud dashboard as a read-and-inspect surface, and the CLI plus migration files as the source of truth. If your schema only exists because someone clicked it into being, you have no history and no way to reproduce it, which is exactly the trap to avoid.

Before you create a single table, decide your auth model and your tenancy model. Supabase Auth gives you sign-up, sign-in, magic links, and OAuth providers out of the box, and it issues a JWT that carries the user's identity into every database query. Row-level security (RLS) reads that identity. So the order is: enable auth, then design tables, then write RLS policies, never the reverse.

How to actually use it

The core loop is: model the data, secure it, expose it, and read it back to prove it works. Do them in that order every time.

Model the data as migrations. Write the table, its columns, its foreign keys, and its indexes as SQL in a migration file, apply it locally, and only then push it to the cloud. Postgres is a real relational database, so use it as one: foreign keys, constraints, and sensible types, not a bag of text columns.

Secure every table with RLS the same turn you create it. This is the single most important habit. With RLS off, your tables are wide open to anyone holding the anon key, which ships in your frontend. With RLS on and a policy written, the database itself enforces that a user only sees their own rows (or their tenant's rows). Write the policy, then prove it: sign in as one user, query, and confirm you get only the rows you should. A table without a policy is not "to be done later", it is a leak.

Expose the data through the auto-generated API or the client libraries. Supabase reads your schema and gives you a REST and a realtime interface for free, plus typed client libraries. For most reads and writes from your app, the client library against your RLS-protected tables is all you need. Generate TypeScript types from your schema so your app and your database never drift.

Read it back. After any change, query the live data and confirm the actual values are what you expect, not just that a row exists. The whole point of using a real database is that you can verify the truth instead of trusting that the code "should" have written it.

Power moves

Edge functions are where Supabase stops being just a database and becomes a backend. Use them for anything that must not run in the browser: calling a third-party API with a secret key, processing a webhook, running scheduled work. Keep the split clear between functions that require a valid user JWT and functions that run as trusted internal jobs, because mixing the two is how you accidentally expose privileged work to the public.

Pair edge functions with scheduled jobs. Postgres can run cron inside the database, and the clean pattern is a scheduled job that invokes an edge function with a bearer token, so your recurring work lives in code you can test rather than in a tangle of SQL triggers.

Use database functions and triggers for logic that genuinely belongs next to the data: maintaining a denormalised count, stamping an audit column, enforcing an invariant a constraint cannot express. Keep them small and obvious, because logic hidden in the database is logic no one reads until it bites.

Lean on the advisors and the logs. Supabase will tell you about missing indexes, tables without RLS, and security gaps if you ask it. Run those checks before you call anything production-ready, and read the logs when an edge function or a query misbehaves rather than guessing.

Where it fits your stack

Supabase is the data and auth backbone, so most of your stack connects through it. Your frontend (React, Next, or similar) talks to it through the client library. Your deploy host (Vercel and the like) reads its connection details and keys from environment variables, so the database and the app ship together. Payment tools such as Stripe connect through webhooks that land in an edge function, which then writes the result into your tables, giving you one trusted record of who paid for what.

For a growth and operations stack, Supabase becomes the single source of truth that your CRM syncs, your analytics reads, and your internal tools query. The discipline that makes this work is keeping the data in the backend: one home for each fact, read live, never a second hand-maintained copy living in a spreadsheet or a static file that quietly drifts out of date.

Pitfalls to avoid

The first and worst mistake is shipping a table with RLS disabled. It feels fine in development because you are the only user, and it is a wide-open door in production. Turn RLS on and write the policy as part of creating the table, not as a follow-up that never happens.

The second is treating the dashboard as your schema. Click-built tables have no history, cannot be reviewed, and cannot be reproduced. Put every change in a migration file in your repo.

The third is leaking the service-role key. The anon key is meant for the browser and is safe behind RLS. The service-role key bypasses RLS entirely and must live only in server-side code and secrets, never in anything that reaches a user's machine.

The fourth is skipping indexes until queries crawl. Add an index when you add a foreign key or a column you filter on, and let the advisors catch the ones you miss.

The fifth is triggering real auth emails while testing. Magic links and sign-up confirmations hit real inboxes, so use a test persona with password sign-in rather than firing live emails at anyone's address.