Supabase

Supabase is managed PostgreSQL with the usual surrounding parts attached: PostgREST turning tables into a REST API, an authentication service issuing JWTs, a file store, and Deno edge functions for the logic that cannot live in SQL. The browser talks to the database almost directly, and Row Level Security is the thing that makes that acceptable rather than reckless. It removes a backend from the project plan, which is the whole point and also the whole risk.

How we use it

360nutri is the fuller example. Accounts, six-digit email verification and password reset come from Supabase Auth. Meal photographs go to Storage. Every user table carries Row Level Security so a meal row is visible only to the person who logged it. The photo analysis runs in an edge function that calls a vision model and returns calories, macros, ingredients and a confidence score, and a second function generates meal suggestions from the profile and recent history. A pg_cron schedule triggers hourly recipe generation with a cron_control table to switch it off, and account deletion is a single Postgres function that removes meals, profile and auth record together rather than three deletes that can half succeed.

Taxcare Accountancy uses the same platform with no user accounts at all. Services, pages, articles, menus, site settings and newsletter subscribers are PostgREST tables, imagery sits in Storage, and one edge function fetches Google reviews. The content carries its old Drupal node identifiers in the rows, because the site was migrated and the old addresses had to keep working, which is the argument in rebuild the site, keep the URLs.

What it costs you

Row Level Security is the entire security perimeter. The anon key is public by design, so a table with a missing policy or a policy that is broader than intended is a public table, and nobody gets an error to tell them. Policies are also code that runs per row, so a policy with a subquery in it is a performance problem that only appears at data volume.

Free projects pause after a period without traffic, and a paused project is indistinguishable from a broken application to the person looking at it.

The failure we actually had is worth stating plainly. 360nutri's front end still loads from its host, the sign-in screen still renders, you type an email and nothing happens, because the Supabase hostname behind it no longer resolves. The entire backend, database, auth, storage and functions, sat behind one name, and when the name went so did the product. That story is what breaks first when you stop maintaining a side project.

"It is just Postgres" is true of the database and not of anything else. The auth schema, the storage policies and the edge functions are Supabase-shaped, so leaving means rebuilding three services and rewriting every call the client library was making. Those functions are also Deno, a different runtime from the application, with its own dependency style and deploy step.

When we would choose something else

When the rest of the build is already on Cloudflare, we use Workers with D1 and keep the API in one codebase rather than splitting logic between a client, a set of policies and a Deno function. When authorisation is more complicated than rows belonging to their owner, we take plain PostgreSQL and write a real API in front of it, because expressing an approvals workflow in RLS policies is possible and miserable.