Wie unterscheidet sich Supabase Realtime von Polling in WeWeb?

Polling sendet alle N Sekunden eine neue API-Anfrage an die Datenbank — ineffizient bei vielen gleichzeitigen Nutzern und mit Datenverzögerung. Supabase Realtime nutzt eine persistente WebSocket-Verbindung und pusht Änderungen sofort, sobald sie in der Datenbank auftreten. Das ist effizienter, günstiger und bietet echte Echtzeit-UX ohne Code.

Wie viele gleichzeitige Realtime-Verbindungen kann Supabase handhaben?

Supabase Pro (25 USD/Monat) unterstützt bis zu 500 gleichzeitige Realtime-Verbindungen. Für größere Skalierung: Supabase Team (599 USD/Monat) bietet mehr Verbindungen und dedizierte Infrastruktur. Für die meisten deutschen B2B-SaaS-Apps mit bis zu 500 aktiven Nutzern gleichzeitig ist der Pro-Plan ausreichend.

Was ist das einfachste Echtzeit-Feature, das man einem bestehenden WeWeb-SaaS hinzufügen kann?

Ein Live-Aktivitätsfeed: eine Tabelle in Supabase, die Ereignisse protokolliert (neue Anmeldung, neue Bestellung, Statusänderung), plus eine WeWeb-Collection mit aktiviertem Realtime für INSERT-Events. Das Ergebnis: eine sich selbst aktualisierende Liste der letzten Aktivitäten — das überzeugendste Echtzeit-Feature mit dem geringsten Implementierungsaufwand (1–2 Tage).

Echtzeit-Dashboard mit WeWeb + Supabase bauen

Q: Funktioniert Row-Level-Security auch für Supabase Realtime-Events?

Ja. RLS-Policies gelten auch für Realtime-Subscriptions. Ein Nutzer empfängt nur Echtzeit-Events für Zeilen, auf die seine RLS-Policy Zugriff gibt. Das ist entscheidend für Multi-Tenant-Apps: Nutzer aus Firma A sehen niemals Echtzeit-Events von Firma B — die Datenbank erzwingt die Isolation auf technischer Ebene.

Wie Supabase Realtime funktioniert

Supabase Realtime ist eine WebSocket-basierte Schicht über PostgreSQL, die Änderungen in deiner Datenbank in Echtzeit broadcastet. Wenn eine Zeile in einer Tabelle eingefügt, aktualisiert oder gelöscht wird, empfangen alle abonnierten Clients sofort ein Event — ohne Polling.

Die technische Grundlage: Supabase nutzt PostgreSQLs built-in Logical Replication. Änderungen werden über einen Replication Slot erfasst und an den Realtime-Service weitergegeben, der WebSocket-Events an abonnierte Clients sendet.

Für das WeWeb-Frontend bedeutet das: kein interval-basiertes Polling (`setInterval` alle 5 Sekunden die Daten neu laden). Stattdessen: einmalige WebSocket-Verbindung, und die UI aktualisiert sich sofort wenn Daten in der Datenbank geändert werden. Für ein Produktions-SaaS mit vielen gleichzeitigen Nutzern ist das deutlich effizienter als Polling — weniger Datenbankbelastung, niedrigere Infrastrukturkosten und bessere UX.

Realtime in WeWeb konfigurieren

In WeWebs Supabase-Plugin: aktiviere Realtime für eine Collection. Das erstellt automatisch einen WebSocket-Kanal für diese Tabelle. Wenn sich Daten in Supabase ändern, aktualisiert sich die Collection in WeWeb sofort — und alle an diese Collection gebundenen UI-Elemente aktualisieren sich mit.

Konfiguriere, welche Events du empfangen möchtest: - **INSERT**: neue Einträge in der Tabelle - **UPDATE**: geänderte Einträge - **DELETE**: gelöschte Einträge - **ALL**: alle Events

Für ein Dashboard, das neue Bestellungen oder Alerts zeigt: aktiviere INSERT und UPDATE. DELETE brauchst du meist nicht. Weniger Events = weniger WebSocket-Traffic = niedrigere Kosten.

Row-Level-Security funktioniert auch mit Realtime: Nutzer empfangen nur Realtime-Events für Zeilen, auf die ihre RLS-Policy Zugriff gibt. Das ist entscheidend für Multi-Tenant-Apps, bei denen Nutzer nur ihre eigenen Daten sehen dürfen.

Dashboard-Layout für Echtzeit-Daten

Das optimale Dashboard-Layout für Echtzeit-Daten:

**KPI-Karten (oben)**: 3–6 Metriken als große Zahlen. Jede Karte ist an eine Supabase-Abfrage gebunden, die aggregierte Daten zurückgibt (COUNT, SUM, AVG). Mit Realtime aktualisieren sich die Zahlen sofort wenn neue Daten eingehen.

**Aktivitätsfeed (rechts)**: Eine Liste der letzten N Ereignisse, sortiert nach created_at DESC. Mit Realtime werden neue Einträge oben eingefügt ohne Seiten-Reload.

**Tabellen/Diagramme (mitte)**: Zeitreihen-Diagramme für Trends, Tabellen für detaillierte Datensätze. Realtime-Updates für Diagramme sind performance-intensiver — aktualisiere nicht die vollständige Diagrammdaten bei jedem Event, sondern nur den neuesten Datenpunkt.

Für deutsche B2B-SaaS: denke an Zugriffskontrolle auf Dashboard-Ebene. Verschiedene Nutzerrollen sollen verschiedene KPIs sehen — implementiere das mit WeWebs Conditional Visibility basierend auf dem Nutzer-Rollen-Attribut aus Supabase Auth.

Performance-Optimierung für skalierte Dashboards

Echtzeit-Dashboards können die Performance degradieren, wenn nicht richtig implementiert:

**Event-Throttling**: Wenn Events sehr häufig kommen (jede Sekunde), aktualisiere nicht die UI bei jedem einzelnen Event. Sammle Events für 500ms und aktualisiere dann einmal. Implementiert in WeWeb mit einem Debounce-Timer.

**Selektive Subscriptions**: Abonniere nur die Tabellen und Spalten, die du wirklich brauchst. Supabase Realtime unterstützt filter-basierte Subscriptions: `eq` (gleich), `lt` (kleiner als), `gt` (größer als). Nutze das, um nur für deinen Workspace relevante Events zu empfangen.

**Connection-Management**: Jede geöffnete Browser-Tab erstellt eine neue WebSocket-Verbindung. Bei 1.000 gleichzeitigen Nutzern sind das 1.000 offene Verbindungen. Supabase Realtime skaliert das gut, aber füge immer Reconnect-Logik für unterbrochene Verbindungen hinzu.

**Caching für aggregierte Daten**: Berechne KPI-Metriken nicht bei jedem Realtime-Event neu. Nutze Materialised Views in Supabase oder cached Aggregate-Abfragen, die sich alle 30 Sekunden aktualisieren.

Praxisbeispiel: Bestellungs-Dashboard für Mittelstand

Ein konkreter Anwendungsfall: ein Mittelstandsunternehmen in Deutschland (Produktion, Handel) möchte ein Live-Dashboard, das neue Bestellungen, den Produktionsstatus und Lagerbestände zeigt.

**Datenmodell**: `orders` (id, customer, status, value, created_at), `production_jobs` (id, order_id, status, updated_at), `inventory` (id, product_id, quantity, updated_at).

**Realtime-Setup**: Abonniere `orders` für INSERT (neue Bestellungen), `production_jobs` für UPDATE (Statusänderungen), `inventory` für UPDATE (Lagerbestandsänderungen).

**Dashboard**: KPI-Karten für "Bestellungen heute", "Offene Aufträge", "Lager-Warnungen". Aktivitätsfeed für die letzten 20 Ereignisse. Tabelle für offene Bestellungen mit Echtzeit-Status-Updates.

**Ergebnis**: Produktionsleiter sehen sofort, wenn eine neue Bestellung eingeht oder ein Auftragsstatus sich ändert — ohne F5 zu drücken. Das wurde bisher mit Excel-Tabellen und E-Mail-Benachrichtigungen gelöst. WeWeb + Supabase Realtime ersetzt das in 4–6 Wochen.

DSGVO-Überlegungen für Echtzeit-Dashboards

Echtzeit-Dashboards, die personenbezogene Daten anzeigen, haben spezifische DSGVO-Anforderungen:

**Zugriffsbeschränkung**: Nur berechtigte Nutzer sollen bestimmte Daten in Echtzeit sehen. Implementiere das mit Supabase RLS auf Realtime-Subscriptions — Nutzer empfangen nur Events für ihre autorisierten Zeilen.

**Keine unnötige Datenspeicherung im Browser**: Echtzeit-Daten, die nur zur Anzeige benötigt werden, sollten nicht dauerhaft im LocalStorage des Browsers gespeichert werden. WeWeb-Variablen sind session-basiert — das ist standardmäßig richtig.

**Audit-Log**: Für sensible Business-Daten (Finanz, HR) implementiere einen Audit-Log in Supabase, der aufzeichnet wer wann was gesehen hat. Das ist eine Best-Practice für DSGVO-Artikel-5 (Rechenschaftspflicht) und wird von deutschen Unternehmens-DPOs bei Lieferantenaudits geprüft.

**Supabase EU-Region**: Realtime-WebSocket-Verbindungen laufen über die Supabase-Region. Wenn du EU-Region wählst, bleiben alle Daten — auch temporäre Realtime-Events — innerhalb der EU.