Rowy vs. NocoDB: Low-Code-Datenbankplattformen im Vergleich 2026

Rowy und NocoDB werden oft in einem Atemzug genannt: Beide entstanden aus der Idee „Airtable, aber Open Source und ohne Limit bei der Datensatzanzahl". In der Praxis sind es zwei unterschiedliche Werkzeuge mit unterschiedlicher Architektur — und mit sehr unterschiedlicher Entwicklung. NocoDB ist eine Schicht über einer relationalen Datenbank, die Tabellen in eine brauchbare Oberfläche verwandelt. Rowy ist eine Low-Code-Schicht über Firebase/Firestore für Produktteams, die ein Backend ohne Backend-Entwickler brauchen.

Wir haben beide verglichen: Lizenz, unterstützte Datenbanken, Self-Hosting, API, Automatisierung, Preise und — oft das wichtigste Kriterium — die Entwicklungsaktivität. Spoiler: 2026 kann genau dieser Punkt entscheidend sein.

Websites: rowy.io | nocodb.com

Kurzfassung

Gemeinsamkeiten von Rowy und NocoDB:

• offener Quellcode und die Möglichkeit, selbst zu hosten;
• eine Tabellenoberfläche im Stil einer Excel-Tabelle mit typisierten Spalten;
• Rollen und Berechtigungen, Einladung von Teammitgliedern;
• REST-API und Webhooks für Integrationen;
• ein kostenloses Cloud-Angebot plus kostenpflichtige Pläne pro Sitz.

Der Unterschied liegt im Fundament. NocoDB fungiert als Frontend für eine Datenbank: Sie legen eine Base in NocoDB an oder verbinden eine bestehende MySQL-, PostgreSQL-, SQLite- oder SQL-Server-Instanz und erhalten darüber eine komfortable Oberfläche. Die Daten bleiben in Ihrer Datenbank, NocoDB ist die Präsentations- und Kollaborationsschicht.

Rowy funktioniert anders: Es ist ein Dateneditor und eine Umgebung für Cloud-Funktionen, gebunden an Firestore (NoSQL von Google Cloud/Firebase). Es bietet berechnete Spalten, Action-Felder, serverlose JavaScript/TypeScript-Funktionen und eine sofort verfügbare API. Im Kern ist das ein Low-Code-Backend für eine Anwendung, kein Werkzeug für eine Unternehmens-SQL-Datenbank.

Die Schlussfolgerung: Wenn Sie bereits PostgreSQL oder MySQL betreiben, beantwortet sich die Frage „Rowy oder NocoDB" fast von selbst zugunsten von NocoDB. Wenn Sie ein Firebase-Produkt bauen und ein Admin-Panel ohne Code brauchen, liegt Rowy näher — allerdings mit einem Risiko, das wir unten beschreiben.

Vergleichstabelle

Parameter	NocoDB	Rowy
Lizenz	Sustainable Use License (kostenlos für interne und persönliche Nutzung, Weiterverkauf als Dienst verboten)	Apache License 2.0
Datenspeicher	Eigene NocoDB-Datenbank oder externe MySQL, PostgreSQL, SQLite, SQL Server	Firebase / Firestore (NoSQL, Google Cloud)
Stack	TypeScript, Node.js	TypeScript, React, Node.js
Self-Hosting	Ja: Docker, npm, Kubernetes-Manifeste	Ja, erfordert Firebase- und GCP-Projekt
Hauptzweck	Oberfläche für relationale Daten, Airtable-/Google-Sheets-Ersatz für Teams	Low-Code-Backend und CMS für ein Firebase-Produkt
Ansichten	Grid, Gallery, Form, Kanban, Kalender plus Interfaces (Dashboards, Seiten)	Grid mit erweiterten Spaltentypen, Formulare in höheren Tarifen
Spaltentypen	Text, Zahl, Datum, Verknüpfungen, Formeln, Anhänge, Auswahl	30+ Typen, inklusive Derivative- und Action-Feldern
API	REST und GraphQL (v2 und v3), automatisch generiert	Automatische REST-API über Firestore
Automatisierung	Automations (Datensatz-Trigger und Zeitpläne), Webhooks	Cloud Functions (JS/TS), Action-Felder, Webhooks, Scheduled Jobs
Externe SQL-Datenbanken	Ja (ab Business im Cloud-Tarif; bei Self-Hosting unbegrenzt)	Nein
Kostenloses Cloud-Angebot	3 Nutzer, 1.000 Datensätze, 1 GB	1 Projekt, unbegrenzte Datensätze
Kostenpflichtiger Tarif	Plus 12 $/Sitz/Monat (jährlich), Business 24 $, Scale 45 $	Pro 12 $/Sitz/Monat
GitHub	65.300+ Sterne, aktive Commits (letzter Oktober 2026)	6.800+ Sterne, Repository nach buildship-ai/rowy umgezogen, letzter Commit November 2024
Risiko der Aufgabe	Gering	Hoch

NocoDB im Detail

NocoDB startete als „Open-Source-Airtable" und wuchs zur Plattform für interne Werkzeuge: CRM, Ticketverwaltung, Kataloge, Inventar, Dashboards. Die zentrale Funktion ist der Betrieb auf einer bestehenden SQL-Datenbank. Sie verbinden MySQL oder PostgreSQL, NocoDB liest das Schema und erzeugt die Oberfläche: Tabellen, Formulare, Verknüpfungen, Ansichten. Eine Datenmigration ist nicht nötig — ein großer Vorteil gegenüber Airtable und ähnlichen SaaS-Produkten.

Funktionen, die tatsächlich genutzt werden

Ansichten und Interfaces. Neben dem Grid gibt es Gallery (Karten mit Bildern), Form (öffentliches Formular, das direkt in eine Tabelle schreibt), Kanban (nach Statusfeld) und Kalender. Zusätzlich sind „Interfaces" ein Seitenbaukasten, in dem Dashboards für Führungskräfte zusammengestellt werden: Diagramme, Listen, Buttons. Im kostenlosen Tarif ist ein Interface mit bis zu drei Seiten enthalten, in bezahlten Tarifen ohne Limit.

Verknüpfungen. Link-to-record, Lookup, Rollup und Formeln funktionieren wie in Airtable, aber auf einem sauberen relationalen Schema. Für SQL-Kenner ist das der Kompromiss: komfortable Oberfläche, aber ein vorhersehbares und portables Datenmodell.

API. NocoDB generiert für jede Tabelle eine REST- und GraphQL-API. Frontend oder Mobile-App greifen damit auf dieselben Daten zu, die das Team im Grid bearbeitet. Es gibt v2 und v3, wobei v2 ausläuft — neue Integrationen sollten auf v3 setzen.

Automatisierung. Trigger beim Anlegen oder Ändern von Datensätzen, geplante Aktionen, Webhooks, E-Mail- und Messenger-Integrationen. Der kostenlose Tarif erlaubt 100 Automationsläufe pro Monat, Plus 30.000, Business 120.000, Scale 240.000. Dieses Kontingent ist wichtig: Automatisierungen pro Datensatz verbrauchen es schnell.

Zugriffskontrolle. Rollen auf Base- und Tabellenebene, Einladungen per E-Mail, Kommentatoren getrennt von Redakteuren. Business ergänzt private Bases und SAML-SSO, Scale Row-Level-Security und Audit-Logs. Für compliance-kritische Unternehmen ist das essenziell, und die Airtable-Pendants kosten deutlich mehr.

Self-Hosting

NocoDB lässt sich mit einem Docker-Befehl installieren, es gibt ARM-Images (praktisch für Raspberry Pi und günstige VPS), npm und Kubernetes-Manifeste. Ein VPS mit 2 GB RAM reicht für ein kleines Team. Cloud-Limits für Datensätze und externe Verbindungen gelten bei Self-Hosting nicht — bezahlt wird nur die Infrastruktur. Deshalb ist NocoDB bei Teams beliebt, die Daten aus ausländischen SaaS-Diensten herausziehen.

Für Unternehmen in Russland ist das ein zusätzlicher Vorteil: Der Server kann von einem lokalen Anbieter kommen, die Daten bleiben in derselben Jurisdiktion. Die Hardwareanforderungen sind bescheiden, ein günstiger VPS genügt — wir schauen meist bei FirstVDS und Timeweb, wo ein Container in Minuten läuft.

Preise von NocoDB

• Free — 0 $: bis 3 Nutzer (3 Redakteure, 10 Kommentatoren), 1.000 Datensätze, 1 GB Speicher, 100 Automationsläufe, 1.000 API-Aufrufe/Monat, ein Interface mit bis zu drei Seiten.
• Plus — 12 $/Sitz/Monat bei jährlicher Zahlung, praktisch 108 $/Monat für unbegrenzte Sitze ab neun Nutzern: 50.000 Datensätze, 20 GB, 30.000 Automationsläufe, 100.000 API-Aufrufe, unbegrenzte Erweiterungen und Interfaces. Externe Datenbankverbindungen gibt es auf Plus nicht.
• Business — 24 $/Sitz, 216 $/Monat für unbegrenzte Sitze: 300.000 Datensätze, 100 GB, 120.000 Automationsläufe, 1 Mio. API-Aufrufe, 10 externe Datenbankverbindungen, private Bases, SAML-SSO.
• Scale — 45 $/Sitz, mindestens 3 Sitze: 1 Mio. Datensätze, 150 GB, 240.000 Automationsläufe, 5 Mio. API-Aufrufe, Row-Level-Security und Audit-Logs.
• Enterprise — auf Anfrage: SCIM-Provisioning, IdP-Gruppensynchronisierung, persönlicher Ansprechpartner.

Beachten Sie die Logik „für 9 Sitze zahlen, der Rest ist frei": Für ein Team von 20 Personen ist NocoDB Business günstiger als die meisten Konkurrenten mit Preis pro Nutzer.

Nachteile von NocoDB

• Die Oberfläche ist dicht; Neueinsteiger suchen in den ersten Tagen nach Einstellungen.
• Die Performance bei sehr großen Tabellen (Millionen Zeilen) hängt von der externen Datenbank ab — NocoDB ist kein Analyse-Warehouse.
• Mehrere fortgeschrittene Funktionen (externe Verbindungen, SSO, Row-Level-Security) sind teuren Tarifen vorbehalten.
• Automatisierungen sind weniger flexibel als eine echte Workflow-Engine; komplexe Logik gehört weiterhin in Code.
• Die Sustainable Use License ist kein klassisches Open Source: Interne Nutzung ist frei, ein öffentlicher kommerzieller Dienst auf NocoDB-Basis nicht erlaubt.

Rowy im Detail

Rowy war als Hinterhof für Firebase gedacht: eine Tabellenansicht der Firestore-Collections plus die Möglichkeit, Serverfunktionen direkt im Browser zu schreiben. Für ein Firebase-Produktteam ist das wirklich praktisch — Admin-Panel, CMS und API entstehen ohne eigenen Backend-Entwickler.

Funktionen

Firestore-Integration. Rowy verbindet sich mit einem Firebase-Projekt und zeigt Collections als Tabellen. Änderungen in der Oberfläche landen in der Datenbank und umgekehrt. Das ist Zwei-Wege-Synchronisation, kein Import/Export.

Spaltentypen. Mehr als dreißig: Text, Zahlen, Daten, Arrays, Geolocation, Dateien, Verweise auf andere Collections sowie Derivative-Felder (berechnete Werte) und Action-Felder (Buttons, die eine Cloud-Funktion starten).

Cloud Functions. JavaScript/TypeScript-Funktionen direkt aus der Oberfläche, ausgelöst durch Datensatzänderungen oder einen Button in der Zeile. Das ist Rowys stärkstes Szenario: E-Mail bei neuer Bestellung, Rabattberechnung, Aufruf einer externen API.

Import und Export. CSV, TSV, JSON und Airtable — einmaliger Import und kontinuierliche Airtable-Synchronisierung in höheren Tarifen. Der Export im kostenlosen Tarif ist auf 10.000 Zeilen begrenzt, bei Pro unbegrenzt.

Suche und Filter. Volltextsuche und erweiterte Filter gibt es ab Pro.

Preise von Rowy

• Base — 0 $: ein Projekt, unbegrenzte Tabellen und Datensätze, unbegrenzte Cloud-Funktionen und Teammitglieder, Import/Export, 30+ Spaltentypen, Row-Level-Audit.
• Pro — 12 $/Sitz/Monat (10 % Rabatt bei Jahreszahlung): unbegrenzte Projekte, Volltextsuche, Export über 10.000 Zeilen, erweiterte Filter, Code-Klonen zwischen Projekten, GCP-Kostenlimit, E-Mail-Support.
• Business — auf Anfrage: eigene Domain, Priority-Support, Datenversionierung, Audit auf Feldebene, automatische Backups, Formulare.

Die Staffelung wirkt attraktiv, besonders der kostenlose Tarif ohne Datensatzlimit. Aber: Der kostenlose Tarif hängt am eigenen Firebase-Projekt, die Firestore- und Cloud-Functions-Kosten kommen also separat zu Google-Cloud-Preisen dazu.

Das Hauptrisiko: die Entwicklung ist stehengeblieben

Dieser Punkt wiegt schwerer als die technischen Vorzüge. Das Rowy-Repository ist von rowyio/rowy nach buildship-ai/rowy umgezogen, der letzte Commit datiert vom November 2024. Für ein Projekt, das als aktiv entwickelter Open-Source-Dienst auftritt, sind das fast zwei Jahre Stille. Das Unternehmen hat den Fokus offenbar auf BuildShip verlagert, einen visuellen Backend-Workflow-Baukasten.

Was das praktisch bedeutet:

• keine neuen Funktionen und keine Sicherheitsupdates;
• niemand garantiert Kompatibilität mit Änderungen in Firebase/GCP;
• die Discord-Community wird stiller, komplexe Fragen bleiben unbeantwortet;
• wer Rowy im Produktivprozess einsetzt, pflegt faktisch einen Fork.

Für ein internes Werkzeug, das läuft und keine Änderungen braucht, ist das tolerierbar. Für ein neues Projekt 2026 ist es ein ernstes Argument dagegen.

Weitere Nachteile von Rowy

• Harte Bindung an Firestore: Eine Migration auf SQL bedeutet, das Datenmodell neu zu schreiben.
• Die Gesamtkosten sind Abo plus GCP-Verbrauch — bei einem aktiven Projekt kann Letzteres Ersteres übersteigen.
• Keine Unterstützung externer relationaler Datenbanken (anders als NocoDB).
• Self-Hosting erfordert ein Firebase-Projekt und Service Accounts; ohne DevOps ist das eine Hürde.

Testszenarien: die passende Wahl

Wir haben beide Werkzeuge durch typische Aufgaben geschickt, mit denen Leser zu uns kommen.

Szenario 1: Airtable im Vertrieb ersetzen

Gebraucht werden eine Deal-Tabelle, Website-Formulare, ein Status-Kanban und Rollen für Vertrieb und Leitung. NocoDB deckt das komplett im Plus-Tarif ab, die Daten liegen im eigenen PostgreSQL. Rowy kann es auch, aber die Daten müssten nach Firestore wandern — ein Speicherwechsel für eine Oberfläche. Sieger: NocoDB.

Szenario 2: Oberfläche für eine bestehende Datenbank

Sie haben MySQL mit Shop-Daten und wollen dem Support den Zugriff ohne SQL-Client ermöglichen. NocoDB verbindet sich lesend und schreibend und zeigt die Tabellen sofort. Rowy kann das gar nicht. Sieger: NocoDB, ohne Frage.

Szenario 3: Admin-Panel für eine Firebase-App

Die App läuft bereits auf Firebase, die Daten liegen in Firestore, gebraucht wird ein Redaktionspanel plus zwei Serverfunktionen. Rowy steht an einem Abend: Projekt verbinden, Collections wählen, Funktion schreiben. NocoDB bräuchte eine Zwischenschicht und Synchronisierung. Sieger: Rowy — wenn das Projekt nicht über Jahre wachsen soll.

Szenario 4: Zehn Personen, strenge Vorgaben zum Datenstandort

Die Daten müssen auf dem eigenen Server liegen, dazu Audit-Trail und Zeilen-Berechtigungen. Self-hosted NocoDB löst das für den Preis eines VPS; in der Cloud gibt es das Äquivalent in Scale für 45 $/Sitz. Rowy verlangt ein GCP-Projekt mit ausländischer Abrechnung. Sieger: NocoDB.

Szenario 5: Backend-Prototyp am Wochenende

Formular, Datenbank, API, zwei Automatisierungen. Beide passen; Rowy startet auf Firebase etwas schneller, NocoDB ist wartbarer. Die Wahl hängt davon ab, was Sie bereits betreiben.

Kosten für reale Teams

Team	NocoDB	Rowy
3 Personen, bis 1.000 Datensätze	Free — 0 $	Base — 0 $ + GCP-Kosten
10 Personen, bis 50.000 Datensätze	Plus — 108 $/Monat (jährlich)	Pro — 120 $/Monat
20 Personen, bis 300.000 Datensätze	Business — 216 $/Monat (jährlich)	Pro — 240 $/Monat + GCP
50 Personen, SSO erforderlich	Business — 216 $/Monat	Business — auf Anfrage
Eigene Infrastruktur	Self-hosted, nur Serverkosten	Self-hosted + Firebase

Auf dem Papier sind die Tarife ähnlich — 12 $ pro Sitz bei beiden. Doch ab neun bezahlten Sitzen hört NocoDB auf zu wachsen, während Rowys Rechnung linear steigt und Google-Cloud-Kosten obendrauf kommen. Bei 20 bis 30 Personen ist der Unterschied spürbar.

Wer was wählen sollte

NocoDB wählen, wenn:

• eine relationale Datenbank vorhanden ist oder geplant wird (PostgreSQL, MySQL, SQLite, SQL Server);
• Self-Hosting mit Daten auf dem eigenen Server gefragt ist;
• Vorhersehbarkeit zählt: aktive Entwicklung, häufige Releases, lebendige Community;
• interne Werkzeuge entstehen: CRM, Inventar, Buchhaltung, tabellenbasierte Wissensbasen;
• Formulare, Kanban, Kalender und Dashboards an einem Ort gewünscht sind.

Rowy wählen, wenn:

• das Produkt bereits auf Firebase/Firestore läuft;
• ein Admin-Panel mit JavaScript/TypeScript-Cloud-Funktionen ohne separates Backend gebraucht wird;
• das Projekt intern ist und keine langfristige Weiterentwicklung braucht;
• Sie bereit sind, bei Bedarf einen eigenen Fork zu pflegen.

Beides nicht wählen, wenn Sie Analytik über zig Millionen Zeilen brauchen (das ist ClickHouse- und BI-Territorium) oder eine vollwertige Workflow-Engine mit Verzweigungen und komplexer Orchestrierung (dann eher n8n und ähnliche Werkzeuge).

Fazit

2026 ist NocoDB die sicherere Wahl. Es wird aktiv entwickelt, unterstützt externe SQL-Datenbanken, bietet vorhersehbare Preise und bindet Sie nicht an einen Cloud-Anbieter. Für die typische Aufgabe — „meinen Daten eine vernünftige Oberfläche geben und dem Team Zugriff ermöglichen" — deckt es 90 % des Bedarfs ab.

Rowy bleibt ein interessantes Werkzeug mit einer eleganten Idee: Tabelle als Schnittstelle zu Firestore plus Serverfunktionen im Browser. Wer bereits im Firebase-Ökosystem lebt und diese Woche ein Admin-Panel braucht, wird mit Rowy Erfolg haben. Ein neues, mehrjähriges Projekt darauf zu bauen, ist jedoch riskant: fast zwei Jahre ohne Commits sind ein Signal, das man nicht ignorieren sollte.

Unsere Empfehlung: mit NocoDB starten und Rowy als taktische Lösung für eine konkrete Firebase-Aufgabe betrachten — mit Plan B, falls der Support ganz endet.

Auf welcher Seite stehen Sie — schon mit einem der Werkzeuge unterwegs oder noch am Auswählen? Erzählen Sie, welche Aufgabe Sie lösen; aus Lesererfahrungen wird meist schnell klar, wo ein Werkzeug an seine Grenzen stößt.