Airtable-Berater für Basen, die auch den zweiten Anwendungsfall tragen

Airtable ist eine relationale Datenbank mit ungewöhnlich guten Ansichten, und der relationale Teil ist echt. Ein verknüpfter Datensatz ist ein Objekt, auf das beide Seiten verweisen, keine kopierte Angabe. Rollups und Lookups rechnen über diese Verknüpfungen, ohne etwas zu duplizieren: Der Auftragswert pro Kunde oder das letzte Prüfdatum pro Standort ist dann eine Felddefinition und kein gespeicherter Wert, den eine Automation aktuell halten muss und der falsch sein kann.

Der zweite echte Vorteil sind Ansichten und Interfaces. Raster, Kalender, Kanban, Galerie und Zeitleiste sind Fenster auf dieselben Zeilen, jeweils eigens gefiltert, ohne die Daten zu verändern. Interfaces zeigen Menschen, die die Base nicht sehen sollen, genau den Ausschnitt, den ihre Rolle braucht. Deshalb gewinnt Airtable gegen eine Tabellenkalkulation fast immer.

Grenzen hat Airtable bei Abfragen und Skalierung. Eine Ansicht ist eine gespeicherte Frage, keine Abfrage-Engine: Sie verknüpft nicht über Basen hinweg, und verkettete Formeln werden beim Laden neu berechnet. Datensatzlimits gelten pro Base und je nach Plan, die API schreibt zehn Datensätze pro Aufruf, und mehrere Schreibvorgänge lassen sich nicht zu einer Transaktion zusammenfassen.

Ob Sie einen Airtable-Berater, -Experten, -Spezialisten oder -Freelancer suchen, gemeint ist meist dieselbe Arbeit. Bei Skofi macht sie der Gründer Saveez Irfan selbst, vom Datenmodell bis zur Übergabe:

• Ein Datenmodell, bevor die Daten kommen. Viele-zu-viele-Beziehungen bekommen eine eigene Verknüpfungstabelle statt zweier Link-Felder, jedes Feld hat genau einen Ort, und Berechnetes wird berechnet statt eingetippt. Eine halbe Stunde Planung vor den ersten dreihundert Datensätzen entscheidet, ob ein neuer Anwendungsfall eine Ergänzung ist oder ein Umbau.
• Verknüpfungen, Lookups und Rollups statt Skripten. Rollups mit Bedingungen erledigen das meiste, wofür sonst ein Skript geschrieben wird, und ein Lookup hält einen Wert an einer Stelle, statt eine Kopie zu erzeugen, die mit der Zeit abweicht.
• Wenige, klar geregelte Ansichten: gemeinsame Ansichten, auf die sich das Team einigt, persönliche Ansichten für alles Vorübergehende und gesperrte Ansichten dort, wo eine Automation oder ein Interface vom Filter abhängt.
• Interfaces für alle, die die Base nicht sehen sollen: eine Detailansicht mit den Feldern, die die Rolle braucht, eine Liste der eigenen Datensätze und Formulare für Eingaben. So bekommt niemand vollen Zugriff, nur um ein Feld zu ändern, und löscht dabei versehentlich ein Feld, an dem ein Rollup hängt.
• Automationen mit klarer Übergabe: native Automationen für ausgelöste Schreibvorgänge und Benachrichtigungen, ein Skriptschritt, wo die Logik ihn wirklich braucht, und die Übergabe an Make, n8n oder einen kleinen Dienst, sobald mehrere Systeme oder Wiederholversuche im Spiel sind.

• Das Datensatzlimit kommt mitten im Projekt. Anhänge und Versionsverlauf belegen zusätzlich Speicher, deshalb ist die Grenze oft früher erreicht, als die Zeilenzahl vermuten lässt. Die Lösung ist selten ein größerer Plan, sondern ein festgelegter Arbeitsbestand: Ältere Datensätze wandern regelmäßig nach Postgres oder in ein Data Warehouse, und Airtable behält, woran tatsächlich gearbeitet wird.
• Ansichten übernehmen die Arbeit von Abfragen. Dutzende stark gefilterte Ansichten über verketteten Formeln machen eine Base langsam. Das wirkt wie ein langsames Airtable, ist aber ein Modellierungsproblem. Wir lösen Formelketten auf, speichern nur, was wirklich gespeichert werden muss, reduzieren die Ansichten deutlich und verlagern echtes Reporting dorthin, wo Abfragen möglich sind.
• Zwei Systeme schreiben dasselbe Feld. Synchronisierte Tabellen sind in Airtable bewusst schreibgeschützt; schreibt eine Automation trotzdem in die Quelle zurück, laufen Datensätze still auseinander. Die Regel lautet: ein führendes System pro Objekt, Synchronisation nur in diese Richtung, und die betroffenen Felder auf der Empfängerseite schreibgeschützt.
• Integrationen verlieren Schreibvorgänge. Die REST-API nimmt zehn Datensätze pro Aufruf an und begrenzt die Anfragen pro Base. Eine naive Integration, die tausend Zeilen schiebt, stößt an beides. Wir bauen mit Stapeln, seitenweisem Lesen, einer Pause bei der Rate-Limit-Antwort und Wiederholversuchen, die keine Duplikate erzeugen.

Airtables eigene Automationen sind gut für das, wofür sie gebaut wurden: eine ausgelöste Aktion innerhalb einer Base. Eine Integrationsplattform sind sie nicht. Welches Werkzeug passt, lässt sich meist am Symptom ablesen.

Die Logik zu verlagern heißt nicht, Airtable zu verlassen. Häufig bleibt Airtable das führende System, und eine Plattform erledigt über die API die Arbeit zwischen den Systemen, in einer festgelegten Richtung und nur auf definierten Feldern.

Wenn Sie bereits eine Postgres-Datenbank haben und jemanden, der darauf entwickeln kann, ist Airtable meist die falsche Antwort. Sein Vorteil gegenüber einer echten Datenbank liegt in der Oberfläche, nicht in der Speicherung. Operative Daten in ein zweites System zu kopieren, nur um eine schönere Tabelle zu bekommen, erzeugt zwei Versionen der Wahrheit.

Ebenso ungeeignet ist Airtable, wo Daten bei gleichzeitigen Zugriffen konsistent bleiben müssen: bei Geldbewegungen, Lagerbeständen oder überall dort, wo zwei Personen nicht gleichzeitig erfolgreich handeln dürfen. In beiden Fällen bauen wir lieber eine Anwendung über der Datenbank, mit denselben Ansichten und Formularen, aber mit Regeln, die sich nicht umgehen lassen. Und wenn Ihr zentrales Objekt eine Aufgabe ist, die mit einer verantwortlichen Person durch Phasen läuft, ist monday.com die ehrlichere Wahl.

Die Fallstudien auf skofi.tech sind nach Branche anonymisiert und auf Englisch. Eine davon zeigt Airtable in einer typischen Rolle: Für eine medizinische Einrichtung mit mehreren Standorten verbinden Make-Szenarien das Patientenverwaltungssystem mit Airtable, wo das Team für Nachsorge und Recall arbeitet.

• Ein nächtlicher Datenspiegel: Die Szenarien holen nur die Aktivität des Tages, finden Patienten per Patientennummer, legen nur Fehlendes an und verknüpfen jeden Besuch mit Diagnose-, Medikations- und Abrechnungstabellen. Ein erneuter Lauf am selben Tag erzeugt keine doppelten Besuche.
• Ein Recall-Kreislauf: Ob ein Patient fällig ist, entscheidet ein Formelfeld in Airtable. Das Team ändert die Regel, indem es die Formel ändert, nicht das Szenario, und ein Webhook trägt zurück, wer geantwortet oder einen Termin gebucht hat.

Die Fallstudie beschreibt auch, wo der Aufbau aufhört, zum Beispiel dass die Szenarien keine eigenen Fehlerrouten haben und ein ausgefallener Tag nicht automatisch nachgeholt wird.