Supabase

Why we use Supabase

We have used Supabase for authentication and the database since 2023, and it is our primary recommendation whenever a project needs a real backend. The reason is Postgres. Supabase is a real relational database underneath, not a proprietary query layer we would need to learn around, so the data stays portable and standard rather than something we would need to migrate off later if a project outgrew it. We wrote up the fuller reasoning in a post on how we use it.

What it provides

Supabase is a Backend-as-a-Service platform, not just a database: Postgres, authentication, storage, auto-generated APIs, and Edge Functions, all under one project. We rely on most of these directly, not only the database and authentication.

• Postgres. A real relational database, with row-level security we can use to define who can see and change which rows directly in the data itself.
• Authentication. Sign-up, login, password reset, and session handling, the parts of a login screen that are easy to get subtly wrong.
• Storage. File uploads and other objects a project needs to keep, on the same project as the database rather than a separate service.
• Edge Functions. Server-side logic that needs to run close to the data, a webhook handler or a scheduled job, without deploying and monitoring a separate service for it.
• APIs. Available on the same project when a job calls for an auto-generated API, though authentication, the database, storage, and Edge Functions are what we reach for most.

Where it runs

Several of the internal tools we build and use ourselves run on it, and it is also our default recommendation for client work whenever the project is genuinely a web application: a client portal with real accounts, an internal tool for a client’s own staff, a workflow that needs a database rather than a content management system standing in for one. A project with a large existing backend it needs to integrate with, unusual data requirements, or hosting constraints set by the client can still call for a different answer, and we will say so rather than forcing a project onto a stack it does not fit.

For clients where budget, not capability, is the deciding factor, Neon covers the same ground at a lower cost, and we will say so plainly when it is the better fit.