Supabase: Postgres-based backend-as-a-service with EU region Frankfurt

What is Supabase?

Supabase is an open-source alternative to Firebase: backend-as-a-service with PostgreSQL at the core, supplemented by authentication, storage, real-time subscriptions, and edge functions. Founded in 2020 by Paul Copplestone and Ant Wilson in Singapore/UK, in May 2026 in Series C phase with over 100k active projects and EU datacenter presence in Frankfurt and Dublin.

License: Apache 2.0 for the entire stack. Supabase consists of several OSS components -- PostgREST (REST API on Postgres tables), GoTrue (auth server, since renamed Supabase Auth), Realtime (Postgres logical replication as WebSocket stream), Storage API (S3-compatible on own buckets), Edge Functions (Deno-based). Each component is OSS, the entire stack also runs self-host via Docker Compose or Kubernetes.

The killer advantage: Postgres base. Unlike Firebase (proprietary, Google Cloud lock-in) or NoSQL BaaS solutions, Supabase is built on Postgres. This keeps an open standard database system -- every migration option stays open, every Postgres driver works, every SQL capability is available (row-level security, pgvector, PostGIS, window functions, recursive CTEs).

Supabase Cloud offers the following tiers: Free (500 MB Postgres + 50k MAU + 1 GB storage), Pro (USD 25/month for 8 GB Postgres + 100k MAU + 100 GB storage), Team (USD 599 for production setups), Enterprise (custom). EU region Frankfurt is available on all tiers -- with DPA, GDPR-compliant.

In May 2026, Supabase is one of the fastest options to build a production backend in 1-2 days: auth, storage, DB, API, and realtime are configured out of the box. For startups, MVPs, and SaaS products with tight engineering time, it is one of the most popular choices.

Why it matters

Supabase solves a concrete problem in the SME market: fast deployment of a complete backend without weeks of configuration work. Three reasons why Supabase is the default choice for MVPs and startup backends in May 2026.

First: Postgres base instead of proprietary stack. Firebase and comparable BaaS solutions lock you into proprietary data models -- a migration away is a schema redesign. Supabase is Postgres, period. Anyone wanting to switch from Supabase Cloud to self-host in 2 years exports the DB via pg_dump and imports it into their own Postgres server. Edge functions are Deno-based and portable. Auth tokens are JWT standard. Migration paths stay open.

Second: EU datacenter Frankfurt. For GDPR and nFADP compliance, a US BaaS is unacceptable without Standard Contractual Clauses (SCC) plus Transfer Impact Assessment (TIA). Supabase EU region in Frankfurt meets EU data residency, DPA with Supabase Inc. is available. For regulated industries with strictest data residency duty (fiduciary, law, insurance), the self-host option on Hetzner Falkenstein also exists.

Third: Row-Level Security as a feature. One of the best Postgres features for multi-tenant SaaS is Row-Level Security (RLS) -- policies defining which users see which rows. Supabase uses this by default: an authenticated user can only see rows they are authorized for. This enables a secure multi-tenant architecture without heavy application logic.

What speaks AGAINST Supabase? Lock-in risk is moderate but exists: Supabase auth patterns, realtime subscriptions, and edge functions are somewhat proprietary. Anyone wanting 100 percent Postgres-pure builds Postgres + self-hosted PostgREST + auth server. Significantly more effort. Self-host Supabase is available but operationally heavier than the cloud variant.

For Swiss SMEs in May 2026, we see Supabase as the default choice for MVPs, startup backends, and non-regulated SaaS products. For fiduciary and law under strictest nFADP compliance, self-host Postgres on Hetzner remains the safer configuration.

How it works

Supabase is a component stack on PostgreSQL: each component fulfills a specific backend function and communicates with the Postgres instance.

PostgreSQL (version 17 in May 2026): the core. With standard extensions (pgvector, PostGIS, pg_audit, plpgsql), reachable via Postgres wire protocol, PostgREST REST API, and GraphQL (via pg_graphql).

Supabase Auth (formerly GoTrue): JWT-based authentication with email/password, magic link, OAuth (Google, GitHub, Apple, etc.), multi-factor (TOTP, SMS, WebAuthn). Auth tokens are stored in the auth.users Postgres column; via RLS policy app tables join with auth.uid().

Storage: S3-compatible object API with buckets and policies. Files are stored in Supabase's own S3 backend (Cloud) or local MinIO (self-host). Image transforms on the fly, signed URLs for private files.

Realtime: Postgres logical replication as WebSocket stream. App clients subscribe to table changes (INSERT/UPDATE/DELETE) in real time. Channel-based with permissions.

Edge Functions: Deno-based serverless functions, deployed in cloud edge regions. For custom backend logic, webhooks, ChatGPT integration, Stripe checkout validation, email templates.

A sample schema with row-level security:

-- Table with tenant separation CREATE TABLE clients ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), user_id UUID REFERENCES auth.users(id), name TEXT NOT NULL, industry TEXT, created_at TIMESTAMPTZ DEFAULT now() );

-- Enable RLS ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

-- Policy: user sees only own clients CREATE POLICY "Users see own clients" ON clients FOR SELECT USING (user_id = auth.uid());

CREATE POLICY "Users can create own clients" ON clients FOR INSERT WITH CHECK (user_id = auth.uid());

Application code (Next.js, Nuxt, SvelteKit, etc.) uses the Supabase client:

const { data, error } = await supabase .from('clients') .select('*') .order('created_at', { ascending: false });

The client sends a REST request to PostgREST with the JWT token; PostgREST enforces RLS policies and returns only rows the user is allowed to see.

Backup: in cloud automatic (PITR from Pro tier, 7-day retention). Self-host via pg_basebackup + WAL archiving. Migration between cloud and self-host via pg_dump.

Supabase to production in 5 steps

1. 01Create cloud project: supabase.com login, choose EU region Frankfurt, sign DPA with Supabase Inc. Free tier or directly Pro for production.
2. 02Design schema: tables with RLS policies, per table a multi-tenant separation via user_id or tenant_id. Migrations via Supabase CLI (supabase db push).
3. 03Configure auth: integrate OAuth providers (Google, GitHub, Apple), customize email templates (German language for Swiss market), enable MFA for sensitive apps.
4. 04Connect application with Supabase client: @supabase/supabase-js in Next.js/Nuxt/SvelteKit, write Edge Functions in TypeScript, realtime subscriptions per use case.
5. 05Backup strategy and monitoring: enable PITR (Pro tier), check Performance Insights, own pg_dump snapshots to S3-compatible storage as additional safety.

When to use Supabase

The right choice when (a) an MVP or startup backend must run in 1-2 days, (b) auth/storage/realtime/DB are needed out of the box, or (c) EU data residency with DPA compliance is mandatory.

Concrete scenarios: an indie-hacker SaaS MVP with auth requirement (login with email plus Google OAuth), a marketplace app with realtime updates (new listings, bid updates), a fiduciary client portal with multi-tenant RLS, a mobile app backend with push notifications via edge functions, an AI chatbot app with pgvector RAG and user auth.

New 2026 use cases: AI application backend with pgvector + edge functions for LLM calls + auth for user tracking, RAG platform with Supabase as complete backend (storage for documents, DB for embeddings, edge functions for retrieval logic), workflow builder backend with realtime sync between clients.

Self-host Supabase on Hetzner Falkenstein is an option for strictest data residency: Docker Compose stack with all components, own PostgreSQL instance, own MinIO for storage, own edge-function runtime. Operationally heavier than cloud, but 100 percent under your control.

For Swiss SME fiduciary and law: Supabase EU region Frankfurt with DPA is GDPR-compliant and nFADP-fit. DPA with Supabase Inc. (or European subsidiary, depending on contract) is mandatory. For strictest client data under professional secrecy (Art. 321 StGB), self-host is the safer option.

When not to use

For long-term critical production setups in regulated industries with strictest data residency: Supabase EU Cloud is possible with DPA, but self-host Postgres on your own Hetzner hardware remains the safer configuration without external data processors.

For applications that already have Postgres in the stack and need only some Supabase features: often better to complement the stack than adopt Supabase as a whole. A Postgres with self-hosted PostgREST + own auth layer is more effort but offers less lock-in.

For ClickHouse-like analytics workloads: Supabase is Postgres, not columnar. Anyone running > 100M aggregate reports belongs in ClickHouse or DuckDB -- Supabase Postgres is not faster than standard Postgres on analytics.

For extreme high-scale workloads (> 10k QPS write, > 100 GB database): Supabase Cloud Pro tier does not suffice. Team or Enterprise tier needed, or self-host with own Postgres cluster + read replicas. With truly large workloads, check whether a direct self-host stack does not fit better.

For edge-function-centered applications (Cloudflare Workers, Vercel Edge): Supabase Edge Functions are Deno-based and cloud-deployed. Anyone needing multi-region edge performance without lock-in builds on Cloudflare Workers + Postgres directly.

For very simple single-tenant apps without auth or realtime: Supabase is overkill. A Postgres instance suffices and is simpler.

Trade-offs

FAQ

Related topics

Sources

1. Supabase Pricing 2026 · 2026-05
2. Supabase Documentation · 2026-05
3. Supabase Apache 2.0 License (supabase/supabase repo) · 2026-05
4. Supabase EU regions and data residency · 2026-05