Supabase

Supabase is an open-source backend platform built on top of Postgres. It gives you a hosted Postgres database with a stack of services layered around it: auto-generated REST and realtime APIs, authentication, file storage, edge functions, and vector search. The pitch is that you get most of what a serious backend needs without standing each piece up yourself, while the data sits in a real relational database you can query, migrate, and own.

Where it fits

Supabase fits teams who want a proper SQL database as the foundation, not a proprietary document store they will fight later. It is a strong choice when you are building a web or mobile app and want auth, storage, and an API ready on day one, when you want Row Level Security doing your authorisation in the database rather than scattered through application code, or when you need realtime subscriptions and vector search without bolting on separate tools.

It suits founders and small teams who value moving fast but refuse to trade away SQL, relational integrity, and portability to get there. Because it is open source and Postgres underneath, you are not locked into a dialect you cannot leave.

It is a weaker fit if you want a fully managed, opinionated backend that hides the database entirely, or if your team has no appetite for thinking in SQL and RLS policies. The power is in the Postgres layer, and that layer expects you to engage with it.

The honest take

The biggest strength is the foundation: it is real Postgres, so everything you know about indexes, joins, migrations, and the wider Postgres ecosystem of extensions carries straight over, and your data stays portable. Bundling auth, storage, realtime, and functions around that database removes a lot of early plumbing, and Row Level Security is a genuinely good way to keep authorisation close to the data.

The trade-offs are real. RLS is powerful but easy to get subtly wrong, and a misconfigured policy is a security problem, not a cosmetic one, so it demands care and testing. Leaning on the full stack (functions, realtime, the generated client) ties more of your app to Supabase conventions even though the database itself stays portable. As with any platform, the breadth means there is a learning curve before it feels effortless, and you carry responsibility for getting the data model and policies right.

INTERVIEW EWOUD: What is your overall verdict on Supabase, and your star rating out of five?

INTERVIEW EWOUD: Is Supabase in your own stack, and if so, what do you actually run on it and why did you pick it?

INTERVIEW EWOUD: What is the one line you would tell a peer who is deciding whether to build on it?

This guide gets you from a blank Supabase project to a production database that backs a real product: tables, auth, row-level security, edge functions, and the deploy discipline that keeps it sound. It is written for the founder or operator who is building software (their own or a client's) and wants Postgres power without standing up infrastructure by hand. You do not need to be a database administrator, but you do need to respect a few decisions early, because Supabase rewards getting the foundations right and punishes skipping them.

Getting set up

Start by creating a project in the dashboard, and treat the choices it asks for as permanent until proven otherwise. The region matters: put the database close to where your users (or your app's servers) actually are, because every query pays the round-trip. The database password it generates is the one credential you cannot lose and cannot easily rotate without pain, so store it in a real secrets manager from minute one, never in a chat or a sticky note.

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.

INTERVIEW EWOUD: How is your live Supabase project actually set up, region, local-plus-cloud split, and how do you manage migrations and approvals before a schema change lands?

INTERVIEW EWOUD: What is the one Supabase workflow you rely on most day to day (RLS pattern, edge-function-plus-cron pattern, or something else), and how do you prove a change is correct before calling it done?

INTERVIEW EWOUD: What is your hard-won tip for keeping a multi-tenant Supabase database safe and clean as it grows, the thing you wish you had known when you started?

Supabase is an open-source backend platform built around a managed PostgreSQL database, bundling authentication, auto-generated REST and GraphQL APIs, realtime subscriptions, file storage, vector search and edge functions. It is aimed at developers and technical founders who want a full backend without assembling separate services. It offers both a hosted cloud service and a self-hostable Docker stack.

Technical founders and developers who want a managed Postgres database with built-in auth, APIs and realtime, or a self-hosted equivalent.