How We Use Supabase as Our Backend Database

Supabase has run the database behind our own internal tools and client custom software since 2023. Not a trial, not one project, the actual backend for anything we build that needs real accounts and real data rather than a handful of pages.

We have already written about why we picked it. This is the more useful half: how a project actually ends up running on it.

It starts the same way every time

A client rarely asks for Supabase by name. What they describe is a portal, a member area, a dashboard, something with a login. That is the moment custom software becomes the right conversation instead of a website, and it is the moment Supabase becomes the default answer before we have talked about a single feature.

Spinning up a new project takes a few minutes: a fresh Postgres database, authentication switched on, and a set of row-level security policies that decide who is allowed to see or touch which rows. That last part matters more than it sounds. Without it, “who can see this” lives scattered across application code, one check per screen, one place for someone to forget it. With it, the rule lives once, next to the data it protects.

The database comes first, the rest follows

Everything else we use on a project is downstream of one fact: Supabase is Postgres, not a proprietary layer with its own rules to learn. That is what let us treat “set up the backend” as a solved problem instead of a decision to relitigate on every project.

Once the database and auth are in place, the rest gets added only when a project actually needs it, not because it is available:

• Storage, when a project needs to keep files, on the same project as the data rather than a separate service we would have to stand up and wire in ourselves.
• Edge Functions, when something has to run on a server instead of in the browser, a webhook, a scheduled job, a step we do not want a client’s browser tab responsible for.

Both sit behind the same row-level security we already set up for the database, so adding them does not mean re-deciding who is allowed to do what.

Where you would actually find it running

Several of the tools we build and use ourselves are built this way: a CRM for managing clients, contracts, and invoices; a prospecting tool for research and outreach; a project management application for running our own engagements; a personal read-it-later tool. Different jobs, same backend service underneath, because rebuilding that part from scratch on every project was never where the interesting work was.

Client work follows the same shape. A client portal that needs real accounts. An internal tool for a client’s own staff. A workflow that needs an actual database instead of a content management system doing an impression of one. If a project only needs to present information, none of this applies, and we say so before quoting a database and an auth system nobody asked for.

When we build it differently

Supabase is where we start, not a rule we follow past the point it makes sense. A large existing backend a project has to integrate with, data that does not fit a relational model, or hosting constraints the client sets can point somewhere else, and we say so rather than forcing the wrong stack onto a project because it is the one we already know. It is the same call we make on Astro versus Webflow: the project decides, not our own preference.

If you are trying to figure out whether what you need is a website or something with real accounts and data behind it, that question is worth a conversation before either of us commits to an answer. Book a free consultation and tell us what the software needs to do.