How We Use Supabase for Authentication and Databases

We have used Supabase as the backend for custom software since 2023: authentication, the database, storage, and Edge Functions, and those pieces are rarely separable in practice. It is our primary recommendation when a project needs a real backend, not just pages.

That covers two different kinds of work. It runs the internal tools we build and use ourselves. It also runs backend logic for client projects, when the job is a web application rather than a website.

What we actually use it for

Four things, most of the time.

Authentication. Sign-up, login, password reset, session handling, the parts of a login screen that look simple and are not. Getting authentication wrong is not a cosmetic bug, it is a security incident waiting for the right input. Supabase’s auth layer handles the parts that are easy to get subtly wrong, so a project’s time goes toward the workflow the client actually needs.

The database. Supabase is Postgres underneath, which means we are working with a real relational database rather than a proprietary query layer we would need to learn around. Row-level security lets us define who can see and change which rows directly in the database, instead of scattering that logic across application code where it is easier to miss a case.

Storage. File uploads, images, and other objects a project needs to keep, on the same project as the database rather than a separate storage service we would need to stand up and wire in by hand. Access to a stored file follows the same rules we already defined for the data.

Edge Functions. Server-side logic that needs to run close to the data, a webhook handler, a scheduled job, a step that should not run in the browser. Having it on the same platform as the database and auth means one less service to deploy, monitor, and keep in sync with the rest of the project.

Those four pieces cover most of what a custom application needs before the interesting part of the project even starts.

Why we settled on it

We did not choose Supabase because it was new. We chose it because the alternative, for most of the custom software we build, was assembling the same pieces by hand on every project: a database, an auth service, and the glue between them.

Postgres being the actual database underneath matters more than it might sound. It means the data is portable, the query language is one we already know, and we are not locked into a vendor’s specific way of modeling relationships. If a project ever needed to move off Supabase, the data underneath is a standard Postgres database, not a proprietary export format.

The alternative is not usually “build your own from nothing.” It is more often another hosted platform that solves the same problem differently, or a heavier setup than a given project needs. For the size and shape of the applications we build, Supabase has consistently been the better fit.

Where it shows up

Several of the applications we build and use ourselves run on it: a custom CRM for managing clients, contracts, and invoices; a prospecting tool for research and outreach; a project management application for running web design engagements; and a personal read-it-later tool. Different problems, same backend underneath, because the backend is rarely the part that should be different from project to project.

Client work follows the same pattern whenever the project is genuinely a web application: a client portal that needs real accounts and permissions, an internal tool for a client’s own staff, or a workflow that needs a database rather than a content management system pretending to be one. If a project only needs to present information, it does not need any of this, and we will say so before quoting a database and an auth system nobody asked for.

Where we would use something else

Supabase is a default, not a rule. A project with a large existing backend it needs to integrate with, unusual data requirements outside what a relational database handles well, or hosting constraints set by the client can call for a different answer. When that happens, we say so rather than forcing a project onto a stack it does not fit, the same principle that has us build our own site in Astro while recommending Webflow to most of our clients: the right tool depends on the project, not on which one we like using.

If you are trying to decide whether what you need is a website, a database-backed application, or something in between, that is exactly the kind of question worth a conversation before either of us commits to an answer. Book a free consultation and tell us what the software needs to do.