Supabase and Postgres.
Where your data lives, and who can reach it.

Most systems we build keep their data in Postgres, through Supabase. The interesting part is not the database, it is where the access rules live — and the answer should always be "at the data", not "in the pages".

Start a project

The rules that keep your data yours

Deny by default, at the table

Every table has row-level security on, and anonymous access revoked, before it holds anything. A missed check in a page then cannot expose a record, because the database refuses it. That is the difference between a bug and a breach.

Private storage and links that expire

Documents, CVs and uploads live in private buckets reached through signed links with an expiry, never in a public folder with an unguessable name. An unguessable URL is not a permission.

Server-side keys stay server-side

The key that can read everything never reaches a browser. We check the built output for it rather than assuming, because that mistake is invisible until somebody finds it.

Writes that cannot fail silently

The client library does not throw on a failed write, so every money or customer write is checked explicitly. "200 OK, no row" is a real failure mode and it has cost other people real orders.

Migrations, honestly

Applied means proved

A migration is applied when the database’s own schema says the column exists, not when a file is in a folder. We check the live schema rather than the ledger, because the two disagree more often than anybody expects.

Migrate first, deploy second

Pages degrade when a table is missing, so schema goes first and the deploy follows. Hosting platforms do not run your migrations for you.

Row counts before and after

Taken on every deploy that touches data, and reported. "No data changed" should be a measurement, not a reassurance.

When Postgres is the wrong answer

A single JSON document is sometimes enough

One of our live ordering systems keeps its whole store in one document, deliberately, because it is read constantly and written by one shop. The cost is that concurrent writes need care, and we chose it knowing that.

Files are not database rows

Images, PDFs and video belong in storage with a reference in the database. Putting them in the database is how a small system becomes a slow one.

Questions

Before you ask.

Who can see our data?

You, and whoever you grant access to. Access is enforced at the database with row-level security, the service key never reaches a browser, and files sit in private storage behind links that expire.

Can we get our data out?

Yes, at any time, in full. It is your data and the export is a normal thing to ask for rather than an exit event.

Is it GDPR-appropriate?

The architecture supports it: access control at the data, private storage, deletion that actually deletes, and a record of who processed what. You are the controller and we are a processor, which we will put in writing.

What about backups?

Supabase takes platform backups, and for anything irreplaceable we agree an export schedule as well. A backup nobody has restored is a theory, so we test the restore path for systems where it matters.

Ready to get started?

Tell us what you need. We will scope it, price it and build it.

Start a project →

Supabase and Postgres.Where your data lives, and who can reach it.