In vielen Betrieben ist die wichtigste Datenbank gar keine Datenbank, sondern eine geteilte Tabelle. Der Urlaubsplan, die Lieferantenliste, das Angebots-Tracking – alles liegt in Google Sheets oder einer Excel-Datei, auf die mehrere Leute zugreifen. Dieser Artikel zeigt Geschäftsführern und den Menschen, die bei ihnen automatisieren, wie sich so eine Tabelle sauber in n8n einbinden lässt: lesen, schreiben, auf Änderungen reagieren – und ab wann die Tabelle mehr Last als Hilfe ist.
Warum die Tabelle so oft der Startpunkt ist
Eine Tabelle ist niederschwellig: Jeder im Team kann sie öffnen, eine Spalte ergänzen, eine Zeile korrigieren, ohne die IT zu fragen. Genau das macht sie zum natürlichen ersten Schritt einer Automatisierung. Sie müssen nicht erst ein CRM einführen, um einen Prozess zu verbessern – oft reicht es, die vorhandene Tabelle anzuzapfen und die manuelle Tipparbeit drumherum zu entfernen.
Das ist ehrlich gesagt der Regelfall, den ich in Gesprächen mit Betrieben sehe. Wichtig ist nur, dass die Tabelle ordentlich aufgebaut ist: eine Kopfzeile mit klaren Spaltennamen, eine Zeile je Vorgang, keine zusammengeführten Zellen. Wie sehr die Qualität der Eingangsdaten über das Ergebnis entscheidet, habe ich in Datenqualität vor der Automatisierung beschrieben – für Tabellen gilt das doppelt.
Wie n8n eine Tabelle liest und schreibt
n8n bringt einen fertigen Google Sheets-Node mit. Sie verbinden ihn mit einem Dokument und einem konkreten Tabellenblatt; die erste Zeile gilt als Kopfzeile, und n8n benutzt deren Spaltennamen als Feldnamen. Ab dann arbeiten Sie mit „Kundennummer“ oder „Status“ statt mit Zellkoordinaten wie B2.
Die wichtigsten Operationen des Nodes (Dokumentation):
- Get Row(s) – liest Zeilen aus. Über den Parameter Filters grenzen Sie auf eine Spalte plus Suchwert ein und holen so gezielt einen Datensatz; mit „Return All Matches“ auch mehrere.
- Append Row – hängt einen neuen Datensatz unten an.
- Update Row – überschreibt eine bestehende Zeile.
- Append or Update Row – das Upsert: Findet der Node eine passende Zeile, aktualisiert er sie, sonst legt er eine neue an.
Der Schlüssel entscheidet über sauberes Schreiben
Sobald Sie aktualisieren statt nur anhängen, braucht n8n eine Regel, welche Zeile gemeint ist. Dafür gibt es den Parameter Column to Match On: die Spalte, an der n8n den passenden Datensatz wiedererkennt. Wählen Sie hier ein stabiles, eindeutiges Merkmal – Bestellnummer, Kundennummer, eine externe Datensatz-ID. Der Fallstrick: Gibt es zwei Zeilen mit demselben Wert in dieser Spalte, trifft das Update beide. Ohne eindeutigen Schlüssel schreibt die Automatisierung also fröhlich Dubletten fort. Warum ein sauberer Schlüssel je Vorgang die Grundlage jeder verlässlichen Automatisierung ist, steht in Doppelte Aktionen vermeiden.
Beim Schreiben ordnen Sie die eingehenden Daten den Spalten zu – entweder mit „Map Automatically“ (n8n paart gleichnamige Felder automatisch) oder mit „Map Each Column Manually“, wenn die Feldnamen aus dem Workflow nicht exakt den Spaltenüberschriften entsprechen.
Auf Änderungen reagieren: der Google-Sheets-Trigger
Bis hierher holt sich der Workflow die Daten aktiv. Umgekehrt geht es auch: Der Google Sheets Trigger startet einen Workflow, sobald sich in der Tabelle etwas tut – wahlweise bei Row Added, Row Updated oder Row Added or Updated. Ein Vertriebler trägt einen Lead ein, und der Workflow legt ihn im nächsten Schritt sauber im CRM an.
Zwei Dinge sollten Sie wissen. Erstens ist das ein Polling-Trigger: n8n schaut in einem festen Intervall nach, ob sich etwas geändert hat – es ist kein Echtzeit-Signal in der Sekunde der Eingabe. Zweitens liefert der Trigger Datums- und Zeitwerte standardmäßig als fortlaufende Seriennummer statt als lesbares Datum; das lässt sich über die DateTime-Render-Option umstellen. Wer das nicht weiß, wundert sich über kryptische Zahlen im Workflow.
Excel statt Google Sheets?
Wer im Microsoft-Kosmos arbeitet, nutzt statt Google Sheets den Microsoft Excel 365-Node. Die Idee ist dieselbe, zwei Unterschiede sind aber entscheidend. Der Node spricht Excel über die Microsoft-Graph-Schnittstelle an – die Arbeitsmappe muss also online in OneDrive oder SharePoint liegen. Eine lokale .xlsx-Datei auf dem Laptop eines Mitarbeiters erreicht n8n damit nicht. Und die Zeilen-Operationen erwarten eine echte, formatierte Excel-Tabelle, nicht nur lose Zellen.
Der Node kann Zeilen an eine Tabelle anhängen, Spalten und Zeilen auslesen und – analog zum Filter oben – nach einem Spaltenwert die passende Zeile zurückgeben. Was der Node nicht abdeckt, lässt sich per HTTP-Request-Node direkt gegen Microsoft Graph erledigen. Für den Alltag reicht der fertige Node in aller Regel.
Wo die Tabelle an ihre Grenzen stößt
So praktisch der Einstieg über die Tabelle ist – sie ist keine Datenbank, und das rächt sich mit wachsendem Anspruch an vier Stellen:
- API-Limits. Die Google-Sheets-API erlaubt pro Nutzer 60 Lese- und 60 Schreibanfragen pro Minute (300 pro Minute und Projekt), danach antwortet sie mit
429 Too Many Requests(Google-Doku). Ein Workflow, der eine Liste Zeile für Zeile aktualisiert, erreicht diese Grenze schneller als gedacht. Wie man solche Limits sauber abfängt, steht in Rate Limits: wenn die API die Automatisierung bremst – oft ist die bessere Antwort, gebündelt statt Zeile für Zeile zu schreiben. - Größe. Eine Google-Tabelle fasst bis zu 10 Millionen Zellen (Google-Grenzwerte). Das klingt viel, sind bei 20 Spalten aber nur rund 500.000 Zeilen – und lange vorher wird die Tabelle im Browser zäh.
- Keine erzwungene Struktur. Eine Tabelle kennt keine Datentypen, keine Pflichtfelder, keine eindeutigen Schlüssel. Jemand tippt „k.A.“ in eine Zahlenspalte, schiebt eine Spalte nach rechts oder fügt oben eine Zeile ein – und die Automatisierung greift ins Leere oder verarbeitet Unsinn.
- Gleichzeitige Zugriffe. Zwei Workflows – oder ein Workflow und ein Mensch –, die im selben Moment dieselbe Zeile schreiben, überschreiben sich gegenseitig. Eine Tabelle kennt keine Transaktion, die das verhindert. Bei einer echten Datenbank sorgt genau dafür der Unterbau.
Eine geteilte Tabelle ist als Datenquelle völlig in Ordnung, solange die Datenmenge überschaubar bleibt, nur wenige Beteiligte gleichzeitig schreiben und niemand auf erzwungene Datentypen angewiesen ist. Sobald mehrere Automatisierungen parallel schreiben, das Volumen wächst oder die Datenintegrität geschäftskritisch wird, ist der Umstieg auf eine echte Datenbank kein Luxus, sondern überfällig.
Wann die Tabelle bleiben darf – und wann eine Datenbank besser ist
Die Entscheidung lässt sich an ein paar nüchternen Kriterien festmachen:
| Die Tabelle reicht | Zeit für eine Datenbank |
|---|---|
| Wenige hundert bis wenige tausend Zeilen | Zehntausende Zeilen, schnell wachsend |
| Ein, zwei Automatisierungen schreiben | Viele Workflows schreiben gleichzeitig |
| Menschen sollen die Daten direkt sehen und pflegen | Daten sind reine Maschinen-Schnittstelle |
| Ein Fehler ist ärgerlich, aber nicht teuer | Integrität ist geschäftskritisch |
Zwischen beiden Welten gibt es einen Mittelweg: Werkzeuge wie Airtable oder das quelloffene NocoDB fühlen sich an wie eine Tabelle, erzwingen im Hintergrund aber Datentypen und Beziehungen. Und wenn es doch die volle Datenbank sein soll, ist ein PostgreSQL-Server oft die pragmatische Wahl – n8n bringt für beide fertige Nodes mit. Wo genau bei Ihnen die Grenze verläuft, ordne ich in der n8n-Beratung ein.
Fazit
Die geteilte Tabelle ist kein Anfängerfehler, sondern ein völlig legitimer Startpunkt – solange Sie ihre Grenzen kennen. Für viele Prozesse im Mittelstand trägt sie erstaunlich weit, und n8n macht das Lesen und Schreiben zur Sache weniger Klicks. Erst wenn Volumen, Gleichzeitigkeit oder Datenintegrität ernst werden, lohnt der Umstieg.
Ob Ihre Tabelle noch trägt oder Sie längst dagegen anarbeiten, sieht man ihr von außen selten an. Im kostenlosen Prozess-Check schauen wir uns Ihren konkreten Ablauf gemeinsam an: Ich sage Ihnen ehrlich, ob die Tabelle bleiben darf – und an welcher Stelle sich der Wechsel auf einen stabileren Unterbau wirklich rechnet.