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.