Supabase

Database · Auth · Backend

Postgres, authentication, storage and edge primitives in one product when I want a real relational database without operating the infrastructure myself.

Why it earns a place

Why I use it

The important part is Postgres. Supabase gives me a managed relational core plus auth, storage, row-level security and APIs without forcing the data model into a proprietary document database.

Use cases

Best for

PostgreSQL-backed SaaS products
Auth tied to row-level security
Fast prototypes that may become real products
SQL-first data work and geospatial extensions

Start small

Quick start

01
Design the tables first
Define entities, keys and constraints before building the UI. Treat generated APIs as a consequence of a clean schema, not a substitute for one.
02
Enable RLS deliberately
Once client-side access exists, turn on row-level security and write policies around the user/tenant model. Test both allowed and denied paths.
03
Separate service access
Never expose service-role credentials to the browser. Use server routes/functions for privileged work such as imports, administration and scheduled jobs.

Repeatable workflows

Things I come back for

Bulk data

For large imports and enrichment jobs, prefer server-side/batched operations and validate constraints rather than firing thousands of browser requests.

1
Validate and normalize the source data before import.
2
Load in batches from a trusted server-side process.
3
Check constraints, duplicates, and a small sample of records before considering the job complete.

Backups and exports

Keep a recovery path independent from the application UI. Data products deserve repeatable backups and a documented restore process.

1
Choose what must be recoverable and how often.
2
Generate a backup/export outside the normal app UI.
3
Test a restore on a disposable environment before trusting the backup strategy.

Reference

Links