Google Sheets als Backend ist verlockend und oft genau richtig für den Anfang. Wo die Grenze liegt, was Apps Script gegen die API leistet, welche Rate-Limits dich treffen und wie der Umstieg auf eine echte Datenbank aussieht.
Warum die Tabelle als Backend so verlockend ist
Ein Google Sheet ist sofort da. Keine Migration, kein Schema, keine Servereinrichtung. Du schreibst eine Zeile per API oder Apps Script hinein, und ein Mensch kann dieselbe Zeile zwei Sekunden später im Browser sehen und korrigieren. Genau diese Sichtbarkeit macht Sheets als Backend für viele kleine Automationen erstaunlich gut. Ein Lead-Eingang, eine Statusliste, eine Konfiguration, die ein Nicht-Techniker pflegen soll: dafür ist eine Tabelle oft die ehrlich beste Lösung.
Der Fehler ist nicht, mit Sheets anzufangen. Der Fehler ist, nicht zu wissen, ab wann es kippt. Wer das Limit kennt, kann eine Tabelle bewusst und ohne schlechtes Gewissen einsetzen und rechtzeitig umsteigen, bevor sie zur Last wird.
Wann es passt
Sheets passt, wenn die Daten in eine Hand gehören und wenige gleichzeitig schreiben. Eine Automation, die alle paar Minuten ein paar Zeilen anhängt, ist unkritisch. Wenn Menschen die Daten ohnehin ansehen und gelegentlich von Hand anpassen sollen, spielt die Tabelle ihre Stärke aus, denn sie ist gleichzeitig Speicher und Oberfläche. Auch als Zwischenschicht, etwa wenn Daten aus einem Formular erst gesichtet und dann weiterverarbeitet werden, ist sie sinnvoll.
Konkret nutzen wir Sheets dort, wo ein Mensch im Loop bleiben soll und das Volumen klein ist. Ein Beispiel ist die Synchronisation von Formular-Eingängen in ein System, bei dem die Tabelle als prüfbare Zwischenstation dient, bevor die Daten ihr Ziel erreichen.
Wann es nicht passt
Sobald mehrere Prozesse gleichzeitig schreiben, wird es heikel. Sheets kennt keine echten Transaktionen und keine Sperren auf Zeilenebene. Zwei parallele Schreiber können sich überschreiben oder gegen Rate-Limits laufen. Auch bei sensiblen personenbezogenen Daten ist Vorsicht geboten, denn die Zugriffskontrolle ist grob: wer das Sheet sehen darf, sieht alles, eine Trennung pro Datensatz gibt es nicht.
Dazu kommt die Größe. Jenseits einiger tausend Zeilen mit Formeln wird das Sheet träge, und Abfragen über Bedingungen sind langsam und umständlich, weil eine Tabelle keine Indizes wie eine Datenbank hat. Relationen zwischen mehreren Tabellen bildest du nur mit Verrenkungen ab. Spätestens hier ist die Tabelle nicht mehr das richtige Werkzeug, sondern eine Quelle stiller Fehler.
Apps Script gegen die API
Es gibt zwei Wege, programmatisch ans Sheet zu kommen. Apps Script ist JavaScript, das in Googles Umgebung läuft und direkt an Trigger des Sheets gebunden werden kann, etwa bei jeder Bearbeitung. Das ist bequem für kleine, sheet-nahe Logik, aber schwer zu testen, zu versionieren und in eine größere Pipeline einzubinden. Außerdem hat es eigene Ausführungslimits.
Die Sheets API steuerst du von außen aus deinem eigenen Code, egal ob aus n8n, einem Worker oder einem Skript. Du behältst Versionierung, Tests und Fehlerbehandlung in deiner Hand. Für alles, was über eine Bastellösung hinausgeht, ist die API der robustere Weg. Wir binden sie über API-Pipelines ein, sodass das Sheet ein austauschbarer Baustein bleibt und nicht der Kern, der alles zusammenhält.
Rate-Limits und wie du sie überlebst
Die Sheets API hat Kontingente pro Minute, sowohl pro Projekt als auch pro Nutzer. Wer in einer Schleife Zeile für Zeile schreibt, läuft schnell in einen 429-Fehler. Die Lösung ist Batching: statt hundert einzelner Schreibvorgänge sammelst du sie und schickst sie in einem einzigen batchUpdate. Das reduziert die Anfragen drastisch und ist nebenbei deutlich schneller.
Dazu gehört ein exponentielles Backoff. Wenn ein 429 kommt, wartest du steigend lange und versuchst es erneut, statt sofort nachzufeuern. Ohne diese zwei Mechanismen ist jede Sheets-Automation, die etwas Volumen hat, instabil. Sie funktioniert im Test mit fünf Zeilen und fällt in Produktion mit fünfhundert um. Diese Robustheit bauen wir standardmäßig in Ops-Automation ein.
Der saubere Umstieg auf eine echte Datenbank
Wenn das Sheet an seine Grenze kommt, soll der Umstieg kein Neubau sein. Das gelingt, wenn die Tabelle von Anfang an wie eine Datenbank aufgebaut war: feste Spalten, ein Typ pro Spalte, eine eindeutige ID je Zeile, keine verstreuten Formeln, die Logik enthalten. Dann ist die Migration im Kern ein Export der Zeilen und ein Import in eine Postgres-Tabelle mit demselben Schema.
Der größere Teil der Arbeit ist, die Automationen umzustellen, die bisher ins Sheet geschrieben haben. Wenn diese ohnehin über die API liefen und nicht über Apps-Script-Trigger, tauschst du nur das Ziel aus. Genau deshalb lohnt es sich, früh über die API statt über sheet-gebundene Skripte zu arbeiten. Wir migrieren solche Setups regelmäßig auf Supabase, wobei die Datenstruktur erhalten bleibt und die Trennung von Mandanten und Zugriffen erst dadurch sauber möglich wird. Was das für deinen Fall heißt, klären wir über Kontakt.