Supabase shows up in my stack because I want PostgreSQL in production without becoming a DBA for every freelance engagement. Backups, point-in-time recovery, a connection pooler, a dashboard for the client’s operator when I am offline - those are included. I still design the schema. I still write the transactions. I still decide what the client app is allowed to touch.
Postgres first, product second
Food-tech, hospitality, logistics, and EdTech all collapse to the same modeling problem: entities with relations and money. An order has lines. A line has a menu item and modifiers. A rider is assigned to an order. A coupon applies under rules. If that is JSON in Mongo, I will reinvent foreign keys badly. Same point as the SVSFood case study: PostgreSQL’s ACID transactions and foreign keys are why the kiosk, admin, website, and rider app can share one truth.
Prisma as the TypeScript contract
I access Supabase Postgres through Prisma. The schema file is the contract the Next.js admin and the Fastify API both trust. Migrations are reviewed like application code. I do not “quick add a column” in a GUI on production and forget to tell the kiosk.
This is also why React Native stays efficient: the mobile app does not invent its own order shape. It consumes the same types the database already enforces. See why I choose React Native.
Auth and Row Level Security
Supabase Auth issues JWTs. Row Level Security policies decide which rows a role can read or write. That is the right layer for “a rider sees only assigned deliveries” or “an outlet manager sees only their stock.” It is the wrong layer for “capture a payment and decrement inventory atomically while calling PhonePe.” That second sentence is an API transaction.
Realtime without a second stack
When an admin dashboard should tick when a rider taps Delivered, I can subscribe to the orders table. When the write itself must go through inventory locks, I write via Fastify and either emit a WebSocket event or let the dashboard poll a cheap endpoint. I do not add Redis and a custom pub/sub mesh to a three-outlet restaurant until the product has earned that complexity.
When I would leave Supabase for Cloud SQL
If a client already lives in a locked-down GCP project, needs private IP only, or has a compliance review that wants Cloud SQL specifically, I host Postgres there and keep Prisma. Supabase is a default, not a religion. The non-negotiable is PostgreSQL with migrations, not the logo on the dashboard.
SVSFood: what the database actually holds
- Outlets, users, roles.
- Menus, items, variants, add-ons, images.
- Inventory counts and low-stock signals.
- Coupons and redemption rules that work on kiosk and web.
- Orders from every channel, status history, payments.
- Rider assignment, GPS crumbs, proof of delivery.
- Audit log: who changed a price, when.
That list is why “just use Firebase” was never the design. It is also why Docker and GCP stay simple: the hard part is the schema and the transactions. Compute is a container. Data is Postgres. Auth is Supabase. That is enough to scale the products I actually ship.
The full three-layer picture is in How I use Docker, GCP, and Supabase to scale.