Supabase: Postgres-basierter Backend-as-a-Service mit EU-Region Frankfurt

Was ist Supabase?

Supabase ist eine Open-Source-Alternative zu Firebase: Backend-as-a-Service mit PostgreSQL als Kern, ergänzt um Authentifizierung, Storage, Realtime-Subscriptions und Edge-Functions. Gegründet 2020 von Paul Copplestone und Ant Wilson in Singapur/UK, im Mai 2026 in Series-C-Phase mit über 100k aktiven Projekten und EU-Datacenter-Präsenz in Frankfurt und Dublin.

Lizenz: Apache 2.0 für den gesamten Stack. Supabase besteht aus mehreren OSS-Komponenten -- PostgREST (REST-API auf Postgres-Tabellen), GoTrue (Auth-Server, mittlerweile umbenannt zu Supabase Auth), Realtime (Postgres-Logical-Replication als WebSocket-Stream), Storage-API (S3-kompatibel auf eigenen Buckets), Edge-Functions (Deno-basiert). Jede Komponente ist OSS, der gesamte Stack läuft auch Self-Host via Docker-Compose oder Kubernetes.

Der Killer-Vorteil: Postgres-Basis. Im Gegensatz zu Firebase (proprietär, Google-Cloud-Lock-in) oder NoSQL-BaaS-Lösungen ist Supabase auf Postgres aufgebaut. Damit hat man ein offenes Standard-Datenbank-System -- jede Migrations-Option bleibt offen, jeder Postgres-Treiber funktioniert, jede SQL-Fähigkeit ist verfügbar (Row-Level-Security, pgvector, PostGIS, Window-Functions, Recursive CTEs).

Supabase Cloud bietet folgende Tarife: Free (500 MB Postgres + 50k MAU + 1 GB Storage), Pro (USD 25 pro Monat für 8 GB Postgres + 100k MAU + 100 GB Storage), Team (USD 599 für Production-Setups), Enterprise (custom). EU-Region Frankfurt ist auf allen Tarifen verfügbar -- mit AVV (Auftragsverarbeitungsvertrag) DSGVO-konform.

Im Mai 2026 ist Supabase eine der schnellsten Optionen, um einen Production-Backend in 1-2 Tagen zu bauen: Auth, Storage, DB, API und Realtime sind out-of-the-box konfiguriert. Für Startups, MVPs und SaaS-Produkte mit knapper Engineering-Zeit ist es eine der populärsten Wahl.

Warum es wichtig ist

Supabase löst ein konkretes Problem im KMU-Markt: schnelle Inbetriebnahme eines vollwertigen Backends ohne wochenlange Konfigurations-Arbeit. Drei Gründe, warum Supabase im Mai 2026 die Default-Wahl für MVPs und Startup-Backends ist.

Erstens: Postgres-Basis statt proprietärem Stack. Firebase und vergleichbare BaaS-Lösungen sperren in proprietäre Datenmodelle ein -- eine Migration weg ist ein Schema-Redesign. Supabase ist Postgres, Punkt. Wer in 2 Jahren von Supabase Cloud auf Self-Host wechseln möchte, exportiert die DB via pg_dump und importiert sie in einen eigenen Postgres-Server. Edge-Functions sind Deno-basiert und portierbar. Auth-Tokens sind JWT-Standard. Migrations-Pfade bleiben offen.

Zweitens: EU-Datacenter Frankfurt. Für DSGVO und revDSG-Compliance ist ein US-BaaS nicht akzeptabel ohne Standardvertragsklauseln (SCC) plus Transfer-Impact-Assessment (TIA). Supabase EU-Region in Frankfurt erfüllt die EU-Datenresidenz-Vorgabe, AVV mit Supabase Inc. ist verfügbar. Für regulierte Branchen mit strengster Datenresidenz-Pflicht (Treuhand, Anwalt, Versicherung) gibt es ausserdem die Self-Host-Option auf Hetzner Falkenstein.

Drittens: Row-Level-Security als Feature. Eine der besten Postgres-Features für Multi-Tenant-SaaS-Anwendungen ist Row-Level-Security (RLS) -- Policies, die definieren, welche Anwender welche Zeilen sehen dürfen. Supabase nutzt das standardmässig: ein authentifizierter Anwender kann nur Zeilen sehen, für die er Berechtigungen hat. Damit wird eine sichere Multi-Tenant-Architektur ohne aufwendige Anwendungs-Logik möglich.

Was spricht GEGEN Supabase? Lock-in-Risiko ist moderater als bei Firebase, aber existiert: Supabase-Auth-Patterns, Realtime-Subscriptions und Edge-Functions sind etwas proprietär. Wer 100 Prozent Postgres-rein sein will, baut Postgres + selbst-gehostetes PostgREST + Auth-Server. Aufwandsmässig deutlich teurer. Self-Host-Supabase ist verfügbar, aber operativ aufwendiger als Cloud-Variante.

Für CH-KMU im Mai 2026 sehen wir Supabase als die Default-Wahl für MVPs, Startup-Backends und nicht-regulierte SaaS-Produkte. Für Treuhand und Anwalt unter strengstem revDSG-Compliance-Ansatz bleibt Self-Host-Postgres auf Hetzner die sicherere Konfiguration.

Wie es funktioniert

Supabase ist ein Komponenten-Stack auf PostgreSQL: jede Komponente erfüllt eine spezifische Backend-Funktion und kommuniziert mit der Postgres-Instanz.

PostgreSQL (Version 17 im Mai 2026): das Herzstueck. Mit Standard-Extensions (pgvector, PostGIS, pg_audit, plpgsql), erreichbar via Postgres-Wire-Protocol, Postgrest-REST-API und GraphQL (via pg_graphql).

Supabase Auth (früher GoTrue): JWT-basierte Authentifizierung mit Email/Password, Magic Link, OAuth (Google, GitHub, Apple, etc.), Multi-Factor (TOTP, SMS, WebAuthn). Auth-Tokens werden in Postgres-Spalte auth.users gespeichert; via RLS-Policy verbinden sich App-Tabellen mit auth.uid().

Storage: S3-kompatible Objekt-API mit Buckets und Policies. Files werden in Supabase-eigenem S3-Backend gespeichert (Cloud) oder lokalem MinIO (Self-Host). Image-Transformations on-the-fly, Signed URLs für Private Files.

Realtime: Postgres-Logical-Replication als WebSocket-Stream. App-Clients abonnieren Tabellen-Änderungen (INSERT/UPDATE/DELETE) in Echtzeit. Channel-basiert mit Permissions.

Edge Functions: Deno-basierte serverless Functions, deployed in Cloud-Edge-Regionen. Für Custom-Backend-Logik, Webhooks, ChatGPT-Integration, Stripe-Checkout-Validation, Email-Templates.

Ein Beispiel-Schema mit Row-Level-Security:

-- Tabelle mit Tenant-Trennung CREATE TABLE mandanten ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), user_id UUID REFERENCES auth.users(id), name TEXT NOT NULL, branche TEXT, created_at TIMESTAMPTZ DEFAULT now() );

-- RLS aktivieren ALTER TABLE mandanten ENABLE ROW LEVEL SECURITY;

-- Policy: User sieht nur eigene Mandanten CREATE POLICY "Anwender sehen eigene Mandanten" ON mandanten FOR SELECT USING (user_id = auth.uid());

CREATE POLICY "Anwender können eigene Mandanten erstellen" ON mandanten FOR INSERT WITH CHECK (user_id = auth.uid());

Anwendungs-Code (Next.js, Nuxt, SvelteKit, etc.) nutzt den Supabase-Client:

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

Der Client schickt eine REST-Anfrage an PostgREST mit dem JWT-Token; PostgREST setzt RLS-Policies durch und gibt nur Zeilen zurück, die der Anwender sehen darf.

Backup: in Cloud automatisch (PITR ab Pro-Tarif, 7-Tage-Retention). Self-Host via pg_basebackup + WAL-Archiving. Migration zwischen Cloud und Self-Host via pg_dump.

Supabase in 5 Schritten produktiv

1. 01Cloud-Projekt anlegen: supabase.com Login, EU-Region Frankfurt wählen, AVV mit Supabase Inc. abschliessen. Free-Tier oder direkt Pro für Production.
2. 02Schema designen: Tabellen mit RLS-Policies, pro Tabelle eine Multi-Tenant-Trennung über user_id oder tenant_id. Migrations via Supabase CLI (supabase db push).
3. 03Auth konfigurieren: OAuth-Provider einbinden (Google, GitHub, Apple), Email-Templates anpassen (deutsche Sprache für CH-Markt), MFA aktivieren bei sensiblen Apps.
4. 04Anwendung mit Supabase-Client anbinden: @supabase/supabase-js in Next.js/Nuxt/SvelteKit, Edge-Functions in TypeScript schreiben, Realtime-Subscriptions je nach Use-Case.
5. 05Backup-Strategie und Monitoring: PITR aktivieren (Pro-Tarif), Performance-Insights prüfen, eigene pg_dump-Snapshots in S3-kompatiblen Speicher als zusätzliche Sicherheit.

Wann Supabase einsetzen

Die richtige Wahl, wenn (a) ein MVP oder Startup-Backend in 1-2 Tagen lauffähig sein muss, (b) Auth/Storage/Realtime/DB out-of-the-box gebraucht werden, oder (c) EU-Datenresidenz mit AVV-Konformität zum Pflicht gehört.

Konkrete Szenarien: ein Indie-Hacker-SaaS-MVP mit Auth-Pflicht (Login mit Email plus Google OAuth), eine Marketplace-App mit Realtime-Updates (neue Listings, Bid-Updates), eine Treuhand-Mandanten-Portal mit Multi-Tenant-RLS, ein Mobile-App-Backend mit Push-Notifications via Edge-Functions, eine KI-Chatbot-App mit pgvector-RAG und User-Auth.

Neue 2026er-Use-Cases: AI-Application-Backend mit pgvector + Edge-Functions für LLM-Calls + Auth für User-Tracking, RAG-Plattform mit Supabase als Komplett-Backend (Storage für Dokumente, DB für Embeddings, Edge-Functions für Retrieval-Logik), Workflow-Builder-Backend mit Realtime-Sync zwischen Clients.

Self-Host-Supabase auf Hetzner Falkenstein ist eine Option für strengste Datenresidenz: Docker-Compose-Stack mit allen Komponenten, eigene PostgreSQL-Instanz, eigenes MinIO für Storage, eigene Edge-Function-Runtime. Operativ aufwendiger als Cloud, aber 100 Prozent in eigener Hand.

Für CH-KMU-Treuhand und -Anwalt: Supabase EU-Region Frankfurt mit AVV ist DSGVO-konform und revDSG-tauglich. AVV mit Supabase Inc. (oder europäischer Tochter, je nach Vertragslage) ist Pflicht. Für strengste Mandanten-Daten unter Berufsgeheimnis (Art. 321 StGB) ist Self-Host die sicherere Option.

Wann NICHT

Für langzeit-kritische Production-Setups in regulierten Branchen mit strengster Datenresidenz-Pflicht: Supabase EU-Cloud ist mit AVV möglich, aber Self-Host-Postgres auf eigener Hetzner-Hardware bleibt die sicherere Konfiguration ohne externe Auftragsverarbeiter.

Für Anwendungen, die schon Postgres im Stack haben und nur einige Supabase-Features brauchen: oft besser den Stack ergänzen statt Supabase als Ganzes übernehmen. Ein Postgres mit selbst-gehostetem PostgREST + eigener Auth-Schicht ist mehr Aufwand, aber bietet weniger Lock-in.

Für ClickHouse-ähnliche Analytics-Workloads: Supabase ist Postgres, nicht columnar. Wer über 100M Aggregat-Reports laufen lässt, gehört in ClickHouse oder DuckDB -- Supabase-Postgres ist nicht schneller als Standard-Postgres bei Analytics.

Für extreme High-Scale-Workloads (> 10k QPS schreibend, > 100 GB Datenbank): Supabase Cloud Pro-Tier reicht da nicht. Team- oder Enterprise-Tarif nötig, oder Self-Host mit eigenem Postgres-Cluster + Read-Replicas. Bei wirklich grossen Workloads prüfen, ob nicht direkter Self-Host-Stack besser passt.

Für Edge-Function-zentrierte Anwendungen (Cloudflare Workers, Vercel Edge): Supabase Edge Functions sind Deno-basiert und Cloud-deployed. Wer Multi-Region-Edge-Performance ohne Lock-in braucht, baut auf Cloudflare Workers + Postgres direkt.

Für ganz einfache Single-Tenant-Apps ohne Auth oder Realtime: Supabase ist Overkill. Eine Postgres-Instance reicht und ist einfacher.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

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