Rowy Review 2026: Das Low-Code-Backend für Firestore im Detail

Firebase liefert einer Anwendung fast alles: Authentifizierung, Dateispeicher, Datenbank und Serverless-Funktionen. Was fehlt, ist ein vernünftiger Weg, die eigenen Daten anzusehen und von Hand zu korrigieren. Sobald ein Projekt über „Hello World" hinauswächst, wird der Firestore-Editor in der Google-Cloud-Konsole zur Qual: Dokumente öffnen sich einzeln, Massenbearbeitung ist unmöglich, und einen Redakteur oder Support-Mitarbeiter möchte man dort nicht wirklich arbeiten lassen.

Rowy setzt genau dort an. Es ist ein Open-Source-Low-Code-Backend, das Firestore-Collections wie eine gewöhnliche Tabelle darstellt — im Stil von Airtable — und es erlaubt, direkt im Browser TypeScript-Serverlogik zu schreiben. Die Daten bleiben dabei im eigenen Google-Cloud-Projekt und wandern nicht in ein fremdes SaaS.

Dieser Test zeigt, wie Rowy aufgebaut ist, was es 2026 kann, wo es weh tut und ob 12 US-Dollar pro Platz ein fairer Preis sind — oder ob man gleich zu selbst gehosteten Alternativen greifen sollte.

Was Rowy ist

Rowy ist eine Web-Oberfläche über Firebase und Google Cloud. Architektonisch ist das einfach: Rowy speichert keine Daten. Es verbindet sich mit dem eigenen GCP-Projekt, liest die Firestore-Collections und rendert sie als Tabelle. Jede Aktion — Zelle bearbeiten, Datei hochladen, Funktion auslösen — läuft im Namen des eigenen Projekts, nicht über einen Zwischenserver von Rowy.

Daraus folgen zwei Dinge:

1. Die Datenhoheit bleibt vollständig. Man wählt die Speicherregion, verantwortet die DSGVO und zahlt GCP für Reads und Traffic. Rowy wird nie zum Auftragsverarbeiter.
2. Die Kosten haben zwei Teile — das Rowy-Abo plus die Google-Cloud-Rechnung. Bei kleiner Last bleibt der zweite Teil im kostenlosen Kontingent, verschwindet aber nie.

Das Produkt gibt es in zwei Formen: als gehostete App auf rowy.io und als offenes GitHub-Repository, das sich im eigenen Projekt deployen lässt. Das Team nennt über 30.000 Nutzer und rund 6.800 Sterne auf GitHub. Ein Hinweis ist hier wichtig: Das Repository ist in die Organisation buildship-ai umgezogen, die letzte Aktivität im offenen Code stammt von Ende 2024 — der Fokus des Teams liegt inzwischen auf BuildShip.

Erwähnenswert ist BuildShip, die Low-Code-Plattform für APIs, geplante Jobs und Workflows, die dasselbe Team als separates Produkt vorantreibt. Sie ist die Antwort auf „wir brauchen Hintergrundjobs, nicht nur Daten" und zeigt die Richtung der ganzen Linie: von der Tabelle mit Funktionen zum vollständigen Backend-Baukasten.

Vorteile und Nachteile

Was überzeugt

• Tabelle statt Firestore-Konsole. Sortieren, Filtern, Massenoperationen, Einfügen aus der Zwischenablage — alles, was dem nativen Editor seit Jahren fehlt.
• Über 30 Feldtypen plus abgeleitete Felder, die sich bei Änderungen selbst neu berechnen.
• Cloud Functions in der Oberfläche. TypeScript auf derselben Seite wie die Daten, mit Zugriff auf jedes npm-Paket.
• Daten im eigenen GCP-Projekt. Keine Migration und keine Bindung, wenn man die Plattform verlässt.
• Kostenlose Stufe ohne Limits bei Funktionen und API-Aufrufen. Das ist selten — die meisten Wettbewerber begrenzen genau das.
• Rechte für Nicht-Entwickler. Rollen auf Feldebene, Auditing auf Zeilenebene: wer wann was geändert hat.
• Open Source. Der Code lässt sich lesen, forken und anpassen; die Lizenz blockiert kommerzielle Nutzung nicht.

Was stört

• Harte Bindung an Firestore. Wer PostgreSQL, MySQL oder Supabase betreibt, hat hier kein Werkzeug und keinen Workaround.
• Ein Google-Cloud-Projekt mit aktivierter Abrechnung ist Pflicht für Funktionen und einige Integrationen — zusätzlicher Verwaltungsaufwand für kleine Teams.
• Ein Projekt in der kostenlosen Stufe. Ein zweites Projekt bedeutet Pro, und Pro wird pro Platz abgerechnet.
• Das Produkt driftet in Richtung BuildShip. Die Aufmerksamkeit der Entwicklung ist zum neuen Produkt gewandert, das Changelog zeigt es: weniger Kern-Releases.
• Die Oberfläche ist dicht. Neueinsteiger sehen Dutzende Felder, Erweiterungen und Einstellungen und klicken die erste halbe Stunde nur herum.
• Keine mobile App. Nur Browser.

Funktionen im Detail

Die Datentabelle

Der Startbildschirm ist ein Raster, das stark an Airtable erinnert. Spalten entsprechen Firestore-Feldern, Zeilen den Dokumenten. Die Typen reichen von Text und Zahlen über Dateien, Bilder, Referenzen auf andere Collections, Geopunkte, JSON und Arrays bis zu Datumsangaben mit Zeitzone.

Alles, was der Konsole fehlt, funktioniert hier: Bereichsauswahl mit Einfügen aus Excel, Zeilen duplizieren, Bearbeiten per Doppelklick, Suche in der Collection, Filter mit mehreren Bedingungen und gespeicherte Ansichten. Große Collections bekommen Paginierung und virtualisiertes Rendering, damit die Tabelle bei Zehntausenden Dokumenten nicht einfriert.

Abgeleitete Felder sind der stille Held. Der Klassiker ist ein Feld total, das aus price × qty neu berechnet wird. Die Logik steckt in der Feldkonfiguration statt verstreut in Client und Server, was die Datenabweichung deutlich reduziert, die Firestore-Projekte plagt.

Action-Felder sind Buttons in einer Zeile, die eine Funktion auslösen — das Muster „ein Klick, um eine Bestellung zu bestätigen / eine Mail zu senden / einen Index neu zu bauen". Für operative Teams spart das Stunden.

Cloud Functions

Rowy erlaubt TypeScript-Cloud-Functions in einem eingebetteten Monaco-Editor mit Hervorhebung, Autovervollständigung und beliebigen npm-Paketen. Eine Funktion wird an eine Collection und einen Trigger gebunden: Dokument erstellt, aktualisiert, gelöscht oder manuell über ein Action-Feld gestartet.

Praktisch ist das Rowys stärkstes Argument. In einem normalen Firebase-Projekt bedeutet ein Trigger: lokale Umgebung einrichten, Firebase CLI installieren, Funktion in einem separaten Repo schreiben, deployen und später nicht vergessen, erneut zu deployen. In Rowy lautet der Zyklus: Collection öffnen, Funktion hinzufügen, speichern. Für Aufgaben wie „Mail bei Statuswechsel senden" oder „Änderung in eine Analysetabelle schreiben" rechnet sich das schnell.

Grenzen gibt es. Das Debugging ist schwächer als bei einem klassischen Deploy — kein lokaler Runner, keine Breakpoints —, also debuggt man über Logs. Abhängigkeiten werden über package.json in der Oberfläche verwaltet: praktisch für ein, zwei Bibliotheken, unübersichtlich bei zehn Funktionen mit gemeinsamen Modulen.

Webhooks und Erweiterungen

Webhooks holen Daten herein: ein Formular auf der Website, ein Zahlungsereignis, eine externe API-Antwort. Rowy gibt eine URL aus, man schickt JSON per POST, ein Dokument erscheint in der Collection. Schneller lässt sich eine Landingpage nicht mit einer Datenbank verbinden, ohne eigenen Server.

Erweiterungen schicken Daten hinaus: SendGrid für Mails, Slack und WhatsApp für Benachrichtigungen, Algolia und Typesense für die Volltextsuche. Jede wird über wenige Felder konfiguriert und läuft als Hintergrund-Abonnement auf Collection-Änderungen.

Ein durchgetesteter Ablauf: Lead vom Landingpage-Formular trifft den Webhook → Dokument landet in leads → ein abgeleitetes Feld bewertet nach Unternehmensgröße → eine Funktion sendet Mail über SendGrid und eine Slack-Nachricht → Algolia indexiert den Datensatz für die Admin-Suche. Alles auf einem Bildschirm, ohne eine Zeile Infrastrukturcode.

Rechte und Auditing

Für Teams entscheidend: Nicht-Entwickler bekommen Datenzugriff, ohne zusätzliche Befugnisse zu erhalten. Rollen werden pro Tabelle und pro Feld gesetzt — ein Redakteur darf status ändern, aber nicht price. Auditing auf Zeilenebene (erstellt von, geändert von, Zeitstempel) ist in der kostenlosen Stufe enthalten; Auditing auf Feldebene und Backups gibt es in Business.

Eine Einschränkung: Benutzerverwaltung läuft über Firebase Auth, Rowy ersetzt also kein Unternehmens-SSO. Wer „Login nur über Okta" verlangt, hat hier einen Blocker und muss Firebase separat mit einem externen Provider verbinden.

Preise

• Base — 0 $. Ein Projekt, unbegrenzt Collections und Datensätze, unbegrenzt Cloud Functions, unbegrenzte API-Aufrufe ohne Rate-Limit, über 30 Feldtypen, Import und Export von CSV/TSV/JSON, Auditing auf Zeilenebene, Rollen, Discord-Community.
• Pro — 12 $ pro Platz und Monat (10 % Rabatt bei Jahreszahlung). Unbegrenzte Projekte, Volltextsuche, Export über 10.000 Zeilen, erweiterte Filter, Code-Klonen zwischen Projekten, hartes GCP-Abrechnungslimit, E-Mail-Support. Ein Monat kostenlos testen.
• Business — auf Anfrage. Alles aus Pro plus eigene Domain, priorisierter Support, Daten-Versionierung, Auditing auf Feldebene, automatische Backups und Formulare.

Der Punkt, den viele übersehen: 12 $ sind nicht die ganze Rechnung. Die Google-Cloud-Kosten kommen obendrauf. Bei kleinen Projekten bleiben sie meist null — Firestore hat großzügige kostenlose Kontingente, Cloud Functions 2 Millionen Aufrufe pro Monat —, aber aktive Collections und häufige Trigger treiben sie hoch, und niemand überwacht das für einen. In Pro sollte man das GCP-Limit sofort aktivieren.

Die Rechnung ist einfach: Spart Rowy einem Entwickler einen Tag Admin-Panel-Arbeit oder nimmt einem Ingenieur die Datenpflege ab, sind 12 $ sofort amortisiert. Ein Solo-Entwickler kann ein Produktionsprojekt durchaus in der kostenlosen Base-Stufe betreiben.

Wie wir getestet haben

Wir haben Rowy gegen ein Testprojekt in Firebase deployt: eine Bestell-Collection mit rund 12.000 Dokumenten, 18 Feldern, inklusive Referenz auf eine Kunden-Collection und einem Array von Positionen. Beobachtet wurden drei Dinge: Geschwindigkeit der Oberfläche, Verhalten der Funktionen und Nutzbarkeit für Nicht-Entwickler.

Einrichtung. Der Web-Assistent erledigt das: Google-Login, Projektauswahl, passende Rollen für das Servicekonto, Initialisierung der Rowy-Collections. Der erste Lauf dauert etwa zehn Minuten, davon geht das meiste für Abrechnung und IAM drauf, nicht für das Produkt.

Die Tabelle. Bei 12.000 Dokumenten blieb die Oberfläche flüssig: geschmeidiges Scrollen, Filter mit spürbarer, aber tolerierbarer Verzögerung, weil jede Abfrage Firestore trifft und als Reads abgerechnet wird. Das Einfügen von 200 CSV-Zeilen lief fehlerfrei, dauerte aber deutlich länger als in einer lokalen Tabelle — der Preis des Serverless-Modells, kein Rowy-Fehler. Das Massen-Update eines Feldes über 500 Dokumente brauchte mehrere Durchläufe: Ein Teil lief in die Grenzen für Firestore-Batch-Operationen.

Funktionen. Ein Trigger auf Statuswechsel mit Mailversand über SendGrid funktionierte beim zweiten Speichern — die erste Version scheiterte an einem fehlenden Paket, weil Abhängigkeiten manuell in package.json gehören. Danach stabil. Logs sind in der Oberfläche lesbar, bestätigen aber, dass Debugging die Schwachstelle ist: Ohne lokalen Emulator nervt die Schleife aus Speichern und Loglesen.

Ein Nicht-Entwickler. Ein Redakteur ohne technischen Hintergrund beherrschte Filter und Feldbearbeitung nach etwa 20 Minuten — vermutlich das beste Signal des Produkts. Feldsperren funktionierten wie erwartet: Ein verbotenes Feld ist schlicht nicht editierbar.

Fazit des Tests: Rowy nimmt tatsächlich die Routine um Firestore herum weg, macht Firebase aber nicht zur relationalen Datenbank und ist bei Massenoperationen kein Wundermittel.

Alternativen

• Airtable — hübscher und einfacher, aber die Daten liegen bei Airtable und nicht bei einem selbst, und die Team-Preise beißen. Rowy gewinnt bei Datenhoheit und Backend-Logik.
• Retool — stärker bei internen Tools (Formulare, Dashboards, Dutzende Komponenten), aber kein Daten-CMS und kein Firestore-Admin-Ersatz. Oft ergänzen sich beide, statt zu konkurrieren.
• NocoDB und Baserow — Open-Source-Tabellenoberflächen für SQL-Datenbanken (PostgreSQL, MySQL). Wer nicht auf Firebase setzt, schaut dort.
• Eigenes React-Admin-Panel — flexibel und kostenlos, aber Wochen Arbeit und dauerhafte Pflege. Rowy ist günstiger, solange die Aufgaben typisch bleiben.

Für wen es passt

Kaufen, wenn: Firebase/Firestore im Einsatz ist, operative Daten (Bestellungen, Leads, Katalog, Nutzer) regelmäßig gepflegt werden müssen und vor allem Nicht-Entwickler Zugriff brauchen, ohne dass ein eigenes Admin-Tool gebaut wird. Gutes Zeichen: Man öffnet schon jetzt die GCP-Konsole, um ein Feld zu korrigieren, und verbrennt fünf Minuten für eine Fünf-Sekunden-Aufgabe.

Nicht kaufen, wenn: die Datenbank nicht Firestore ist; Unternehmens-SSO out of the box gebraucht wird; schwere Analytik und Massen-ETL geplant sind — dafür gibt es BigQuery und Spezialwerkzeuge. Zweimal überlegen sollte man auch, wenn die Produktrichtung planbar sein muss: Der Fokus des Teams liegt inzwischen bei BuildShip.

Der Zwischenfall ist ein Startup, das auf Firebase gestartet ist und langsam nach PostgreSQL wandert. Rowy hilft dort nicht: Es erleichtert die Migration nicht und wird danach nutzlos. Als langfristige Admin-Basis taugt es nur, wenn Firestore sicher ein bis zwei Jahre die Hauptdatenbank bleibt.

Fazit

Rowy ist ein schmales, präzise zugeschnittenes Werkzeug. Es will keine universelle Low-Code-Plattform sein und kämpft nicht mit Retool um Dashboards; es stopft ein konkretes Loch in Firebase — das Fehlen einer menschlichen Oberfläche für Daten — und macht das sauber.

Stärken: die Tabelle, abgeleitete und Action-Felder, eingebaute TypeScript-Funktionen, volle Datenhoheit. Schwächen: nur Firestore, schwaches Funktions-Debugging und wachsende Konkurrenz um die Aufmerksamkeit des Teams durch BuildShip.

Für ein Firebase-Projekt, in dem Daten öfter als einmal pro Woche von Hand bearbeitet werden, deckt die kostenlose Base-Stufe die meisten Bedürfnisse ab, und Pro für 12 $ pro Platz ist für unbegrenzte Projekte und Volltextsuche fair. Für alle anderen Stacks ist Rowy schlicht das falsche Werkzeug — was es nie anders behauptet hat.

Bewertung: 8 von 10 — ein hervorragendes Spezialwerkzeug mit ehrlichem Preismodell und einer erheblichen Einschränkung: nur eine unterstützte Datenbank.