NocoDB Test 2026: die Open-Source-Alternative zu Airtable im Detail

Früher oder später läuft jedes Team gegen dieselbe Wand: Die Daten liegen in Google Sheets, die Tabelle wächst auf hundert verknüpfte Blätter, Formeln brechen bei jedem eingefügten Zeileneintrag, und die Hälfte der Belegschaft bearbeitet die falsche Spalte. Airtable hat dieses Problem elegant gelöst — und dazu eine Rechnung pro Nutzer sowie die unangenehme Frage mitgebracht, ob Kundendaten wirklich in einer fremden Cloud liegen sollen.

NocoDB ist die populärste Antwort auf beide Fragen zugleich. Es ist eine Open-Source-Plattform, die eine gewöhnliche SQL-Datenbank in eine smarte Tabelle mit Formularen, Kanban, Rollen und REST-API verwandelt. Das Projekt entstand aus der Idee „Airtable auf der eigenen Datenbank" und hat bis 2026 über 50.000 GitHub-Sterne, zehntausende Self-Hosted-Installationen und ein vollwertiges kommerzielles Cloud-Produkt gesammelt.

In diesem Test schauen wir uns an, wie NocoDB innen funktioniert, was es wirklich gut kann, wo es weh tut, was die Cloud kostet und was ein eigener Server tatsächlich bedeutet — mit einem ehrlichen Fazit am Ende: Wer sollte migrieren, und wer bleibt besser bei Airtable oder schaut sich Baserow an.

Was NocoDB ist und wie es aufgebaut ist

Die zentrale Architekturentscheidung ist einfach — und genau deshalb wertvoll: NocoDB speichert Ihre Daten nicht in einem eigenen Format. Die Plattform verbindet sich mit einer bestehenden relationalen Datenbank — PostgreSQL, MySQL/MariaDB, SQLite, in neueren Versionen auch Microsoft SQL Server — und legt eine Weboberfläche im Tabellenstil darüber.

Was das konkret bedeutet:

• Jede NocoDB-Tabelle ist eine echte Tabelle in Ihrer Datenbank. Jede Spalte ist eine echte Spalte. Jede Zeile ist ein normaler Datensatz.
• Sie können sich jederzeit per psql mit derselben Datenbank verbinden, SQL ausführen, Daten an ein BI-Tool oder an eine bestehende Anwendung geben.
• Würde NocoDB morgen verschwinden (Open-Source-Projekte sind sterblich), lägen Ihre Daten weiterhin in einer Standarddatenbank — nicht in einem geschlossenen Export.

Auch der Stack ist nichts Exotisches: Node.js im Backend, Vue im Frontend, alles als Docker-Image verpackt. Für Self-Hosting heißt das: ein docker run plus ein paar Umgebungsvariablen — kein Cluster, kein Objektspeicher zwingend, kein Redis.

Wichtig ist der Unterschied zwischen den beiden Lieferformen, denn hier entsteht ständig Verwirrung:

1. NocoDB Open Source — die kostenlose Variante, die Sie selbst betreiben. Kernfunktionen: Tabellen, Ansichten, Rollen, API, Webhooks. Grenzen gibt es bei fortgeschrittenen Enterprise-Themen wie SSO, Audit-Logs und feingranularen Rechten.
2. NocoDB Cloud — der Managed Service der Entwickler, bei dem sie die Infrastruktur betreiben. Dort liegen auch die kostenpflichtigen Tarife mit höheren Limits.

Die dritte, am wenigsten bekannte Option ist die externe Datenbank: Sie hängen eine bereits laufende Postgres-Instanz Ihres Produkts an NocoDB und bekommen eine bequeme Admin-Oberfläche über Produktionsdaten. Praktisch für Support und Analyse — aber Vorsicht: Eine Weboberfläche ersetzt keine Migrationen.

Für wen NocoDB wirklich sinnvoll ist

Aus der Praxis betrachtet entfaltet NocoDB seine Stärken in vier Szenarien.

Interne operative Tabellen. Leichtgewichtiges CRM, Kundenstamm, Ticket-Tracker, Lager, Vertragsregister. Alles, was früher in Google Sheets lag und dort nicht mehr hineinpasst.

Ersatz für eine selbstgebaute Admin-Oberfläche. Wenn eine Datenbank existiert und ein Interface für Operator gebraucht wird — Formulare, Filter, Rechte — deckt NocoDB 80 % davon ohne eine Zeile Frontend-Code ab.

Schicht über einer Legacy-Datenbank. Eine alte MySQL-Basis aus der Buchhaltung, an die niemand heranwill. NocoDB gibt ihr eine sichere menschliche Oberfläche mit rollenbasiertem Zugriff.

Schneller Produkt-Prototyp. Wenn über Nacht ein funktionierendes CRUD-Backend mit API gebraucht wird und kein Nest.js-Sprint.

Und wo NocoDB nicht hingehört:

• Als Primärdatenbank eines hochlastigen Produkts mit tausenden gleichzeitigen Nutzern.
• Als Dateispeicher oder Mediathek — Anhänge funktionieren, aber das ist kein S3.
• Als Ersatz für ein echtes BI-System: Pivots und Diagramme gibt es, tiefe Analytik nicht.
• Für Teams, die Offline-Modus und native Mobile-Apps auf Airtable-Niveau brauchen.

Vor- und Nachteile

Vorteile

• Open Source mit echtem Self-Hosting — ohne „cloud-only"-Einschränkungen.
• Daten liegen in Ihrer SQL-Datenbank, vollständig per SQL und jedem Client erreichbar.
• Die kostenlose Version ist für Teams von 10–20 funktional vollständig.
• REST- und GraphQL-API out of the box für jede Tabelle, dokumentiert in der Oberfläche.
• Viele Ansichten: Grid, Formular, Galerie, Kanban, Kalender, Karte.
• Rollen von Owner bis Nur-Lesen und Kommentator.
• Webhooks und Automatisierungen auf Datensatz-Ereignisse.
• Aktive Community und häufige Releases; das Projekt lebt.

Nachteile

• Die Oberfläche ist teils schwer: Bei 50+ Spalten und Zehntausenden Zeilen beginnt der Browser zu denken.
• Formeln und Rollups funktionieren, bleiben aber hinter Airtable in Tiefe und Fehlersuche zurück.
• Automatisierungen sind bescheiden: komplexe Verzweigungen und externe Trigger brauchen Workarounds.
• Keine nativen Mobile-Apps — nur eine responsive Webversion.
• Self-Hosting verlangt Können: Docker, Reverse Proxy, Backups, Updates sind Ihre Aufgabe.
• Major-Upgrades erfordern gelegentlich manuelle Schema-Migrationen.
• Einige Enterprise-Funktionen (SSO, Audit, granulare Rechte) sind kostenpflichtig.

Funktionen: was NocoDB 2026 wirklich kann

Ansichten

Eine Tabelle, viele Ansichten — und das ist keine Marketingzeile. Grid ist der Basismodus mit Filtern, Sortierung, Gruppierung und fixierten Spalten. Formular veröffentlicht einen öffentlichen Link und sammelt Daten von außen ohne Datenbankzugriff. Galerie zeigt Datensätze als Karten mit Covern — praktisch für Kataloge. Kanban gruppiert nach einem Statusfeld inklusive Drag-and-drop. Kalender bindet Datensätze an Daten, Karte an Koordinaten.

Jede Ansicht speichert ihre Filter und Einstellungen separat. Für Operator heißt das: derselbe Datenbestand erscheint als „alle Tickets", „meine offenen Tickets" und „überfällig" — ohne doppelte Tabellen.

Feldtypen

Die Auswahl ist breit: Text, Zahl, Datum und Zeit, Checkbox, Einfach- und Mehrfachauswahl, E-Mail, URL, Telefon, Währung, Prozent, Bewertung, Formel, Rollup, Lookup, Beziehungen (eins-zu-eins, eins-zu-viele, viele-zu-viele), Dateianhänge, JSON, Geodaten, Barcode, Langtext und ein Benutzer-/Zuständigkeitsfeld.

Beziehungen werden über echte Fremdschlüssel abgebildet und nicht über Text-IDs — das merkt man bei Migrationen und beim Zugriff von außen.

API

Jede Tabelle erhält automatisch eine REST-API: Datensätze listen mit Filtern und Paginierung, anlegen, ändern, löschen, Massenoperationen. Dazu ein GraphQL-Endpunkt für komplexe Abfragen und Zugriffstoken, beschränkt auf Tabellen.

Das ist der Punkt, der NocoDB von „nur eine hübsche Tabelle" unterscheidet: Sie können einen Bot, ein Python-Skript oder eine Mobile-App gegen dieselbe Datenbank über eine dokumentierte API schreiben, während das Team die Daten weiterhin manuell im Browser pflegt.

Rollen und Zugriff

Ebenen: Owner, Creator, Editor, Commenter, Viewer. Rechte werden pro Base und pro Tabelle vergeben. Dazu öffentliche Ansichtslinks — mit oder ohne Passwort, Downloads von Anhängen optional deaktivierbar.

In der Open-Source-Edition sind granulare Rechte (auf Zeilen- und Spaltenebene) begrenzt — einer der Hauptgründe, warum Unternehmen eine kostenpflichtige Lizenz kaufen.

Webhooks und Automatisierungen

Webhooks feuern beim Anlegen, Ändern und Löschen von Datensätzen und senden JSON an Ihren Endpunkt. Der eingebaute Automatisierungs-Builder schafft einfache Ketten: „bei Statuswechsel — E-Mail senden", „nach Zeitplan — Datensatz anlegen", „bei neuem Datensatz — externe API aufrufen".

Für echte Orchestrierung reicht das nicht — üblicherweise dient NocoDB als Datenquelle und die Logik liegt in n8n, Make oder einem eigenen Service.

Preise: Cloud gegen eigenen Server

Hier ist Klarheit wichtig, denn das Tarifraster von NocoDB hat sich mehrfach geändert und exakte Beträge sollten Sie beim Lesen auf der offiziellen Website prüfen.

Open Source (self-hosted) — kostenlos. Das vollständige Docker-Image, ohne Limits bei Datensätzen, Tabellen und Nutzern. Sie zahlen nur den Server.

Cloud Free — ein kostenloser Tarif für kleine Teams: gut zum Kennenlernen, aber mit Limits bei Nutzern und Zeilen.

Cloud-Tarife — pro Platz bei jährlicher Zahlung. Höhere Pläne heben die Platzlimits auf: Es gibt Angebote mit „unbegrenzten Nutzern für eine feste Monatsgebühr" — für 15–30 Personen ist das rechnerisch günstiger als Airtable Team.

Self-hosted Business/Enterprise — eine kostenpflichtige Lizenz für die eigene Installation, berechnet pro Editor (nicht pro Leser). Bringt SSO, Audit, erweiterte Rechte und Prioritäts-Support.

Die einfache Rechnung, die man im Kopf behalten sollte: Ein VPS, der NocoDB mit 5–10 GB Datenbank trägt, kostet weniger als zehn Cloud-Plätze. Genau deshalb ist Self-Hosting das Hauptszenario dieses Produkts.

Praxistest: NocoDB auf einem VPS installieren

Wir haben NocoDB zweimal aufgesetzt: mit Docker Compose und PostgreSQL auf einem VPS sowie als „SQLite im Container" zum Vergleich.

Ressourcenbedarf

• Minimum: 2 vCPU, 2 GB RAM, 20 GB SSD — für Teams bis 10 Personen und Datenbanken mit Hunderttausenden Datensätzen.
• Komfortabel: 4 vCPU, 4–8 GB RAM, NVMe — für 20–50 aktive Nutzer und Millionen Zeilen.
• PostgreSQL statt SQLite — bei mehr als ein paar Gigabyte Daten oder mehr als fünf Nutzern. SQLite ist gut für einen Test, aber Schreibsperren machen sich bemerkbar.

Eine Compose-Datei mit zwei Diensten (nocodb + postgres) läuft in fünf Minuten. Nach außen muss nur Port 8080 hinter einem Reverse Proxy mit TLS — Nginx oder Caddy, letzteres ist bei Zertifikaten einfacher.

Wo hosten

Wählen Sie einen Hoster mit lokalem Blech und voller Kontrolle. Wir haben die Installation auf Timeweb Cloud laufen lassen — dort gibt es Docker-fertige Images und privates Networking, praktisch, wenn Postgres später auf eine eigene Maschine wandert. Für minimales Budget passte FirstVDS: einfachere Konfigurationen, aber ehrliches KVM ohne Panel-Aufschlag. Die Domain wurde bei REG.RU registriert, das auch kostenloses DNS-Management bietet.

Was wir manuell geprüft haben

Geschwindigkeit der Oberfläche. Eine Tabelle mit 60.000 Zeilen und 25 Spalten öffnet in 1,5–2 Sekunden, Filtern ist sofort, Paginierung funktioniert. Bei 500.000 Zeilen beginnt das Grid spürbar zu hängen: NocoDB lädt seitenweise, aber Sortierung über ein nicht indiziertes Feld erzwingt Warten. Fazit: Indizes in der Datenbank bleiben wichtig, und sie lassen sich per SQL leichter ergänzen als über die UI.

CSV-Import. Eine 40-MB-Datei mit 200.000 Zeilen war in etwa einer Minute hochgeladen, mit korrekter Typerkennung. Umlaute und Sonderzeichen überstanden den Import unbeschadet — wichtig für lokalisierte Projekte.

Suche. Die Volltextsuche arbeitet auf ILIKE-Niveau der Datenbank, also ohne Stemming. Für anspruchsvolle Suche ergänzt man pg_trgm oder einen externen Index.

Rollen. Wir haben „Operator sieht nur eigene Tickets" getestet: In der Open-Source-Edition ist das ein Ansichtsfilter plus separates Konto, keine echte Row-Level-Security. Echtes RLS gibt es nur kostenpflichtig oder über Views in der Datenbank selbst.

Backups. Einen eingebauten Backup-Scheduler gibt es nicht. Die funktionierende Lösung: pg_dump per Cron in Objektspeicher plus ein separates Backup des Anhang-Volumes. Das ist das Erste nach der Installation — eine Oberfläche ohne Datenbank wiederherzustellen ist sinnlos.

Updates. Image-Tag tauschen und docker compose up -d — das war es. Bei Minor-Versionen gab es keine Probleme; bei einem Major-Upgrade war einmal eine manuelle Migration nötig. Vor dem Sprung die Release Notes lesen.

Anhänge. Dateien liegen lokal im Container-Volume oder in S3-kompatiblem Speicher. Wenn das Team gescannte Verträge hochlädt, ist S3 Pflicht — sonst wächst das Volume-Backup unkontrolliert.

Was gefehlt hat

• Ein echtes Änderungsprotokoll pro Datensatz (Audit Log) — in der kostenlosen Version nicht vorhanden.
• Massenbearbeitung von Formeln über die Oberfläche.
• Klare Diagnose langsamer Abfragen: Man landet in den Postgres-Logs.

NocoDB gegen die Konkurrenz

Airtable. Airtable ist in Details weiterhin angenehmer: Interfaces, Automatisierungen, Mobile-Apps, Ökosystem. Aber die Daten liegen beim Anbieter, und der Preis pro Platz für 20 Personen wird unangenehm. NocoDB gewinnt bei Kontrolle und Betriebskosten, Airtable bei der Politur.

Baserow. Der nächste Open-Source-Konkurrent. Baserow setzt auf Einfachheit und ein eigenes Datenformat (unterstützt inzwischen aber ebenfalls externe Datenbanken). Die Oberfläche ist hübscher und schneller; NocoDB ist tiefer beim Anschluss bestehender SQL-Datenbanken und bei der API-Schicht.

SeaTable. Stark bei Formeln und Tabellenlogik, näher an Excel. Deutsches Projekt mit solide Self-Hosting, aber kleinerer Community.

Teable. Junges Projekt mit moderner Oberfläche und Fokus auf Performance; für sehr große Tabellen vielversprechend, Ökosystem und Doku sind aber noch dünner.

Google Sheets. Kostenlos und vertraut, bietet aber keine Rollen, keine Beziehungen und keine API-Disziplin. Sobald mehr als zwei Personen bearbeiten und Entitäten verknüpft sind, ist Zeit für den Wechsel.

Fazit

NocoDB ist 2026 die beste Wahl, wenn Sie eine Airtable-ähnliche Schicht über der eigenen SQL-Datenbank brauchen und bereit sind, einmal einen Abend in Docker, Domain und Backups zu investieren. Dafür bekommen Sie volle Datenkontrolle, kostenlose Nutzung für Teams jeder Größe und eine API, an die alles angebunden werden kann.

Nehmen Sie NocoDB nicht, wenn das ganze Team nicht technisch ist und niemand den Server verantwortet; wenn Sie Automatisierungen auf Airtable-Niveau brauchen; wenn native Mobile-Apps entscheidend sind; oder wenn strikter Audit und Row-Level-Security ohne Lizenzkauf Pflicht sind.

Am besten geeignet für: Produkt- und Ops-Teams von 5–30 Personen, Agenturen, kleine SaaS-Projekte auf Postgres und alle, die es leid sind, pro Platz für Cloud-Tabellen zu zahlen.

Empfehlung für die Einführung: Starten Sie mit der Self-Hosted-Version auf einem VPS mit 4 GB RAM und PostgreSQL — das reicht für das erste Jahr. Behandeln Sie NocoDB als Schicht über der Datenbank, nicht als einzigen Datenort, richten Sie pg_dump am ersten Tag ein und legen Sie Anhänge nach S3. Wenn das Team nach einem Monat aktiv damit arbeitet, schauen Sie auf eine Lizenz für SSO und Audit — nicht umgekehrt.

Und wie sind Ihre internen Tabellen organisiert — noch Google Sheets oder schon etwas wie NocoDB?