Skip to main content

No servers of our own, Deno, and a single provider: the backbone

RestaPro Team
Product & Platform

September was the moment to pick the technology. In many projects this conversation drags on for months; we wanted to close it in a week. The question was not "what stack is best?" but "what stack lets two people move fast and sleep at night in production?".

The short answer: Supabase and nothing else to start. No servers of our own, no Kubernetes, no Java. The long answer is this post.

What we ruled out on purpose​

There were options that looked sensible on paper and we crossed off without flinching:

  • Java + Spring Boot. It is what we know from previous jobs, but it means servers to maintain, slow deploys, and memory consumption that is absurd at our size.
  • Microservices. For a two-person team, they are an elegant way to create problems you do not have. We started with a frontend monolith and serverless functions.
  • Bare-metal servers of our own. Attractive long-term for cost reasons, but not for an MVP. When we are billing enough, we will revisit.

Why Supabase​

Supabase gives us four things on a single platform that would otherwise be four separate contracts:

  1. Managed Postgres. A serious database, not an exotic NoSQL. SQL gives us flexibility for reports, joins, and predictable migrations.
  2. Native RLS (Row Level Security). Critical for multi-restaurant: each workspace only sees its own data, guaranteed at the database level. No "oh, I forgot to filter by restaurant_id".
  3. Built-in auth. Email, password, magic link, recovery. All the boring stuff we would otherwise have to rewrite.
  4. Storage. For menu photos, logos, documents. Without spinning up an S3 bucket and signing URLs by hand.

Edge functions in Deno​

For server logic (webhooks, integrations, short jobs) we picked Supabase edge functions, which run on Deno. Three reasons:

  • TypeScript directly, no build pipeline. You write and you deploy. Ideal for one-off integrations.
  • They start in milliseconds. No idle servers, zero cost when nothing is calling them.
  • Same language as the frontend. No mental gear-shifting between client and server.

For long-running processes (bulk email sends, the initial sync with TheFork) edge functions will not cut it. We will solve those cases as they come up, probably with queues and workers.

What this implies​

This architecture has a price: we depend heavily on Supabase. If they change pricing tomorrow or have a long outage, we suffer. We accept that in exchange for moving fast. And the foundation is standard Postgres, so migrating to another managed provider down the line is hard work but not traumatic.

Up next: how we ended up modeling the data so a group with three locations can manage everything from a single account.

ESENCA