Der Unterschied zeigt sich schon beim ersten Anlegen einer Spalte. In einer Tabellenkalkulation ist eine Spalte ein Behälter für beliebige Zeichen; ob dort ein Datum, eine Zahl, eine Notiz oder ein Tippfehler steht, entscheidet die Person, die tippt. In Airtable wird eine Spalte als Feld mit Typ definiert: einzeiliger Text, langer Text, Zahl, Datum, Auswahl aus einer Liste, Kontrollkästchen, Anhang, E-Mail, Telefonnummer, Person aus dem Arbeitsbereich, Verknüpfung zu einem Datensatz einer anderen Tabelle. Diese Typisierung ist der eigentliche Kern des Produkts. Sie erzwingt Datenqualität, ohne dass jemand Regeln durchsetzen muss, und sie ermöglicht danach alles, was sinnvolle Auswertung überhaupt erst voraussetzt: Filtern, Gruppieren, Sortieren, Verdichten, Automatisieren.
Der zweite Kernbegriff heißt Base. Eine Base ist eine kleine relationale Datenbank für einen abgegrenzten Zweck — etwa das Produktdatenmanagement, die Redaktionsplanung oder die Auftragsabwicklung eines Bereichs. Sie enthält mehrere Tabellen, die über Verknüpfungsfelder miteinander in Beziehung stehen. Wer in der Tabelle „Projekte“ ein Feld anlegt, das auf die Tabelle „Kunden“ verweist, hat damit eine Beziehung modelliert, wie sie in klassischen Datenbanken über Fremdschlüssel entsteht — nur ohne SQL, ohne Schemamigration und ohne Datenbankadministration.
Die meisten Airtable-Projekte im Mittelstand beginnen als Ablösung einer Excel-Datei, die aus dem Ruder gelaufen ist. Typische Symptome kennt jede Fachabteilung: Die Datei heißt Planung_final_v7_NEU, liegt in drei Versionen auf zwei Laufwerken, enthält verbundene Zellen, farbige Markierungen mit ungeschriebener Bedeutung und Formeln, die niemand mehr erklären kann. Der eigentliche Fehler liegt dabei nicht bei Excel, sondern in der Zweckentfremdung: Eine Tabellenkalkulation ist ein hervorragendes Rechen- und Analysewerkzeug, aber keine Mehrbenutzer-Datenhaltung mit Beziehungen und Zugriffsregeln.
Airtable dreht die Verhältnisse. Ein Datensatz ist ein eigenständiges Objekt mit Feldern, nicht eine Zeile mit Zellen. Er lässt sich einzeln öffnen, kommentieren, mit Anhängen versehen und in einen Verlauf schreiben, der zeigt, wer wann was geändert hat. Statt einer Datei existiert eine Datenquelle, auf die mehrere Menschen gleichzeitig zugreifen und die verschiedene Ansichten unterschiedlich darstellen. Was in Excel als getrennte Blätter für getrennte Abteilungen entstehen würde, ist hier ein Bestand mit gefilterten Perspektiven. Damit verschwindet die Klasse von Fehlern, die aus abweichenden Kopien entsteht — die häufigste und teuerste Fehlerquelle gewachsener Tabellenlandschaften.
Was Airtable dagegen nicht ersetzt, ist die analytische Tiefe einer Tabellenkalkulation. Komplexe Finanzmodelle, Szenariorechnungen, Pivot-Analysen über viele Dimensionen, mathematisch anspruchsvolle Auswertungen: Dafür bleibt Excel das bessere Werkzeug. Die saubere Arbeitsteilung lautet daher häufig, die Datenhaltung nach Airtable zu verlagern und für Analyse und Berichtswesen weiterhin die vorhandenen Werkzeuge zu nutzen — angebunden über Export, Schnittstelle oder ein Auswertungswerkzeug.
Wer aus der Softwareentwicklung kommt, sieht in Airtable eine relationale Datenbank mit angenehmer Oberfläche — und stellt schnell die richtigen Fragen. Gibt es referenzielle Integrität? Transaktionen? Indizes? Migrationen? Die ehrliche Antwort lautet: Airtable bietet vieles davon in vereinfachter, teils implizierter Form, aber nicht mit der Strenge eines Datenbankmanagementsystems. Verknüpfungen sind komfortabel, aber nicht mit erzwungenen Integritätsregeln in jeder Konstellation. Formeln, Roll-ups und Nachschlagefelder ersetzen viele Abfragen, aber keine freie Abfragesprache mit Optimierer.
Dieser Verzicht ist eine Gegenleistung, keine Schwäche. Er tauscht die letzten Prozent an Kontrolle gegen einen enormen Gewinn an Geschwindigkeit und Zugänglichkeit. Eine Fachabteilung kann eine Struktur an einem Tag entwerfen, am zweiten befüllen und am dritten mit Formularen und Automatisierung produktiv nutzen. Für die Klasse von Anwendungen, die andernfalls überhaupt nicht entstanden wäre — weil kein Budget, kein Entwickler und kein Projektauftrag zur Verfügung standen —, ist das ein echter Fortschritt. Entscheidend ist nur, die Grenze zu kennen und rechtzeitig zu erkennen, wann eine Anwendung diese Klasse verlässt.
In der Beratungspraxis begegnen uns drei wiederkehrende Rollen. Erstens als Fachanwendung für einen Bereich: Produktdaten, Prüfmittel, Maschinenpark, Lieferantenbewertung, Schulungsnachweise, Messeplanung. Zweitens als Projekt- und Ressourcenverwaltung, wenn klassische Projektwerkzeuge zu starr sind, weil neben Aufgaben auch Objekte, Verträge, Assets oder Kunden geführt werden müssen. Drittens als Schaltstelle zwischen Systemen, in der Daten aus mehreren Quellen zusammenlaufen und für einen bestimmten Zweck aufbereitet werden, bevor sie weitergegeben werden.
In allen drei Rollen gilt derselbe Erfolgsfaktor: Airtable belohnt gute Datenmodellierung und bestraft ihre Abwesenheit gnadenlos. Eine Base, die aus einer sauber gedachten Struktur entstanden ist, bleibt jahrelang wartbar und wächst mit. Eine Base, die als abgetippte Excel-Tabelle mit vierzig Spalten begonnen hat, wird zur Belastung, sobald die zweite Abteilung mitarbeiten möchte. Der Aufwand liegt damit nicht im Werkzeug, sondern im Denken vorab — und genau dort setzt eine gute Einführung an.
Die kostenfreie Stufe erlaubt das Anlegen von Bases, das Arbeiten mit den wichtigsten Feldtypen, mehrere Ansichten, Formulare und einfache Automatisierung. Sie ist damit weit mehr als eine Demonstration — für einen Prototypen, eine Machbarkeitsprüfung oder eine kleine Arbeitsgruppe reicht sie regelmäßig aus. Begrenzt sind typischerweise die Menge an Datensätzen je Base, der Speicher für Anhänge, die Tiefe des Änderungsverlaufs, die Zahl der Automatisierungsläufe sowie erweiterte Ansichts-, Verwaltungs- und Sicherheitsfunktionen. Die konkreten Werte gehören in die Anbieterprüfung, weil sie sich regelmäßig verschieben.
Aus Governance-Sicht ist der kostenfreie Einstieg die kritischste Konstellation. Weil er ohne Beschaffung, ohne IT und ohne Vertrag funktioniert, entstehen Bases mit echten Unternehmensdaten an Stellen, die niemand kennt. Wir empfehlen deshalb, vor jeder bewussten Einführung zu prüfen, ob Airtable im Haus bereits inoffiziell genutzt wird — die Antwort lautet häufiger Ja als erwartet. Ein sauberer Weg besteht darin, bestehende private Nutzung in einen verwalteten Arbeitsbereich zu überführen, statt sie zu verbieten und damit in den Untergrund zu drücken.
Die mittleren Stufen adressieren den Übergang vom Experiment zum Betrieb. Typisch für diese Ebenen sind höhere Kapazitäten je Base, ein längerer Änderungsverlauf und die Möglichkeit, ältere Zustände wiederherzustellen, erweiterte Feldtypen und Berechnungen, mehr Automatisierungsvolumen, zusätzliche Ansichtstypen sowie feiner steuerbare Berechtigungen. Ebenfalls hier verortet sind meist die Funktionen, mit denen Daten aus anderen Quellen in eine Base synchronisiert werden können, und ein erweitertes Rechtemodell auf Tabellen- und Feldebene.
Für den Mittelstand ist die Business-Ebene häufig die erste, auf der eine Anwendung wirklich betriebsfähig wird. Der Grund ist selten spektakulär, sondern nüchtern: Erst hier lassen sich Zugriffe so gestalten, dass eine externe Partei oder eine benachbarte Abteilung mitarbeiten kann, ohne die gesamte Datenbasis zu sehen. Genau dieser Punkt entscheidet in der Praxis darüber, ob eine Lösung über den Kreis ihrer Erfinder hinaus tragfähig ist. Wer diese Anforderung früh formuliert, wählt die Edition nicht nach Kapazitätsgrenzen, sondern nach Berechtigungsbedarf — die deutlich klügere Reihenfolge.
Die Enterprise-Ebene richtet sich an Organisationen, in denen Airtable nicht in einem, sondern in vielen Teams parallel läuft. Im Vordergrund stehen die zentrale Verwaltung aller Arbeitsbereiche, die Anbindung an die Identitätsverwaltung mit Single Sign-on und automatisierter Nutzerverwaltung, unternehmensweite Sicherheits- und Freigaberichtlinien, erweiterte Protokollierung und Auditfähigkeit, Steuerung externer Freigaben sowie erweiterte Administrationsschnittstellen. Ergänzend werden auf dieser Ebene üblicherweise Themen wie erweiterte Verschlüsselungsoptionen und regionale Datenhaltung verhandelbar — was für europäische Organisationen der eigentlich interessante Punkt ist.
Die ehrliche Einordnung für den Mittelstand lautet: Diese Ebene rechnet sich erst, wenn die Plattform zum verbindlichen Standard erklärt wurde und entsprechend viele Menschen damit arbeiten. Kleinere Organisationen fahren häufig besser, den Einsatz bewusst auf wenige benannte Arbeitsbereiche mit klarer Verantwortung zu begrenzen und dort die Governance sauber zu halten, statt eine unternehmensweite Verwaltungsschicht für zwei Anwendungsfälle zu finanzieren. Wer allerdings absehbar mit personenbezogenen Daten in größerem Umfang arbeitet, sollte die Verfügbarkeit der Sicherheits- und Residenzfunktionen früh prüfen, weil sie die Editionswahl faktisch vorgeben können.
Eine Base bündelt alle Tabellen, die zu einem Zweck gehören. Innerhalb einer Base sind Verknüpfungen möglich, über Base-Grenzen hinweg nur über Synchronisation oder Schnittstellen. Diese Eigenschaft ist beim Entwurf entscheidend: Der Zuschnitt einer Base bestimmt, welche Daten später ohne Umwege in Beziehung gesetzt werden können. Ein häufiger Anfängerfehler besteht darin, für jedes Thema eine eigene Base anzulegen und dann festzustellen, dass die Kundentabelle in fünf Varianten existiert. Die belastbare Regel lautet: Stammdaten gehören dorthin, wo sie gemeinsam gebraucht werden — und werden von dort in andere Bases gespiegelt, nicht kopiert.
Die Feldtypen sind das Herzstück. Neben den erwartbaren Typen für Text, Zahl, Währung, Prozent, Datum, Auswahl, Mehrfachauswahl, Kontrollkästchen, Bewertung, E-Mail, Telefon und URL gibt es Typen, die eine echte Anwendung ausmachen: Anhang für Dateien und Bilder direkt am Datensatz, Mitarbeiterfeld für Zuständigkeiten, Barcode für Inventarisierung, Formel für berechnete Werte, Roll-up für Verdichtungen über verknüpfte Datensätze, Nachschlagefeld für das Durchreichen von Werten aus verknüpften Tabellen, sowie automatisch geführte Felder für Erstellungszeit, letzte Änderung und Änderungsurheber. Letztere sind für Nachvollziehbarkeit wertvoll und datenschutzrechtlich gleichzeitig relevant, weil sie personenbezogene Metadaten erzeugen.
Besonders wirksam ist der Feldtyp Verknüpfung zu einem anderen Datensatz. Er ersetzt das, was in Excel als Nachschlageformel gebaut würde, und macht daraus eine echte Beziehung, die in beide Richtungen sichtbar ist. Wer in der Tabelle „Aufträge“ einen Kunden verknüpft, sieht in der Tabelle „Kunden“ automatisch alle Aufträge dieses Kunden. Auf dieser Basis lassen sich Summen, Zählungen, Maxima und Statusverdichtungen bilden, ohne jemals eine Abfrage zu schreiben. Diese Mechanik erklärt einen Großteil des praktischen Nutzens der Plattform.
Eine Tabelle wird in Airtable nie nur auf eine Weise dargestellt. Ansichten sind gespeicherte Perspektiven mit eigener Filterung, Sortierung, Gruppierung, Feldsichtbarkeit und Farbgebung — auf demselben Datenbestand. Die Grid-Ansicht ist die tabellarische Grundform für Pflege und Massenbearbeitung. Die Kanban-Ansicht gruppiert Datensätze nach einem Auswahlfeld in Spalten und macht Arbeitsfluss sichtbar. Die Kalender-Ansicht ordnet Datensätze nach Datumsfeldern und ist die natürliche Sicht für Redaktions-, Kampagnen- und Terminplanung. Die Timeline- beziehungsweise Gantt-artige Ansicht zeichnet Vorgänge mit Start- und Enddatum entlang einer Zeitachse und eignet sich für Vorhaben mit Laufzeiten. Die Gallery-Ansicht stellt Datensätze als Karten mit Vorschaubild dar — die richtige Wahl für Produkte, Assets, Bewerbungen oder Medieninhalte.
Zwei Punkte sind dabei wichtig. Erstens: Ansichten sind kein zweiter Datenbestand. Wer in der Kanban-Ansicht eine Karte verschiebt, ändert den Wert des zugrunde liegenden Auswahlfeldes — auch in allen anderen Ansichten. Zweitens: Die Timeline-Ansicht ist keine vollwertige Netzplantechnik. Echte Vorgänger-Nachfolger-Logik mit automatischer Terminverschiebung, kritischem Pfad und Kapazitätsabgleich gehört nicht zum Kern der Plattform. Wer Bauzeitenpläne oder mehrstufige Programmpläne mit Abhängigkeiten braucht, ist mit einem klassischen Projektwerkzeug besser bedient. Für Vorhaben mit überschaubarer Verflechtung ist die Zeitachse hingegen völlig ausreichend und deutlich pflegeleichter.
Formulare sind der oft unterschätzte Hebel. Ein Formular ist eine Eingabemaske auf eine Tabelle, die extern geteilt werden kann und Datensätze direkt in die Struktur schreibt. Damit lässt sich Datenerfassung von der Datenhaltung trennen: Der Antragsteller, der Bewerber, der Kollege aus der Produktion oder der Lieferant füllt ein schlankes Formular aus und sieht die Datenbank nie. Für die Datenqualität ist das ein Sprung, weil Pflichtfelder, Auswahllisten und Feldtypen die Eingabe führen. Für den Datenschutz ist es gleichzeitig eine Stelle, die Aufmerksamkeit verdient: Ein öffentlich erreichbares Formular sammelt personenbezogene Daten und braucht daher Zweckbindung, Hinweistext und eine dokumentierte Rechtsgrundlage.
Die Interface-Funktion ist der Punkt, an dem aus einer Base eine Anwendung wird. Ein Interface ist eine gestaltete Oberfläche, die auf Daten der Base zugreift, aber selbst bestimmt, was sichtbar ist und was bearbeitet werden darf: Listen, Detailseiten, Kennzahlen, Diagramme, Filterelemente, Schaltflächen. Für die Nutzenden bedeutet das, dass sie keine Tabellenlogik verstehen müssen. Für die Verantwortlichen bedeutet es, dass die Datenstruktur weiterentwickelt werden kann, ohne die Oberfläche zu zerstören.
Genau deshalb ist die Empfehlung eindeutig: Sobald mehr als eine Handvoll Menschen mit einer Base arbeitet, sollte der Zugang über Interfaces erfolgen und nicht über die Rohtabelle. Das reduziert Fehlbedienung, macht die Anwendung erklärbar und begrenzt die Sichtbarkeit auf das Notwendige. Ergänzt wird das durch das Berechtigungsmodell, das üblicherweise Rollen wie Besitzer, Bearbeiter, Kommentator und Leser kennt und diese auf Arbeitsbereich, Base und — je nach Edition — auf Tabellen- oder Feldebene anwendet. Für externe Beteiligte kommen zusätzlich geteilte Ansichten und Freigabelinks in Betracht, die getrennt zu bewerten sind, weil sie Daten außerhalb der Anmeldung verfügbar machen.
Automations folgen dem bekannten Muster. Ein Auslöser ist ein Ereignis in der Base — ein neuer Datensatz, ein geändertes Feld, ein Datensatz, der in eine gefilterte Ansicht eintritt, ein eingegangenes Formular, ein Zeitplan oder ein eingehender Webhook. Darauf folgen Bedingungen und Aktionen: Datensatz erstellen oder aktualisieren, E-Mail senden, Nachricht in einen Chatkanal schreiben, Dokument erzeugen, einen externen Dienst aufrufen. Die Konfiguration erfolgt in einer geführten Oberfläche, sodass Fachanwender ohne Entwicklungserfahrung tragfähige Abläufe bauen können.
Bewährte Muster aus dem Mittelstand sind unter anderem:
Wo die Klick-Oberfläche endet, beginnt die Skript-Ebene. Airtable erlaubt es, Skripte als Automatisierungsschritt oder als Erweiterung innerhalb einer Base auszuführen, um Daten zu transformieren, komplexe Bedingungen abzubilden oder Massenoperationen durchzuführen. Ergänzend existiert ein Ökosystem an Erweiterungen, die eine Base um Diagramme, Karten, Seriendokumente, Importwerkzeuge oder spezialisierte Auswertungen ergänzen.
Aus Beratungssicht gilt hier eine wichtige Warnung. Sobald in einer Base umfangreiche Skripte die Kernlogik tragen, ist die Grenze der No-Code-Idee überschritten — mit allen Folgen: Es gibt Quellcode ohne Versionsverwaltung, ohne Testumgebung, ohne Dokumentation und meist ohne zweite Person, die ihn versteht. Der pragmatische Umgang besteht darin, Skripte auf klar abgegrenzte, dokumentierte Aufgaben zu beschränken, sie zu kommentieren und außerhalb der Plattform zu sichern. Wer merkt, dass die Logik weiter wächst, sollte offen prüfen, ob der Anwendungsfall nicht besser in ein richtiges Entwicklungsprojekt oder ein Fachsystem gehört.
Wie alle Plattformen dieser Klasse hat Airtable KI-Funktionen in das Produkt integriert. Herstellerneutral beschrieben geht es um vier Bauformen. Erstens KI-gestützte Felder, die aus dem Inhalt anderer Felder etwas Neues erzeugen: eine Zusammenfassung eines langen Freitexts, eine Kategorisierung eines Kundenanliegens, eine Übersetzung, eine extrahierte Information aus einer unstrukturierten Notiz. Zweitens KI-Schritte in Automatisierungen, die dieselbe Leistung ereignisgesteuert erbringen. Drittens Assistenzfunktionen beim Bauen, die aus einer Beschreibung Tabellenstrukturen, Formeln oder Automatisierungsvorschläge ableiten. Viertens agentenartige Ansätze, bei denen mehrere Schritte, Werkzeugaufrufe und Entscheidungen zu einem Ablauf verkettet werden. Verfügbarkeit, Funktionsumfang, Editionsbindung und Abrechnung dieser Funktionen entwickeln sich schnell und sind vor einer Entscheidung beim Anbieter zu prüfen.
Der praktische Nutzen ist real, aber begrenzter, als das Marketing vermuten lässt. KI ist stark bei der Vorstrukturierung unstrukturierter Eingaben — eingehende Anfragen sortieren, lange Notizen verdichten, Freitext in Kategorien überführen, erste Textentwürfe erzeugen. Sie ist schwach überall dort, wo Verlässlichkeit gefordert ist: Eine automatisch erzeugte Kategorie ist ein Vorschlag, kein Fakt. Wer sie ungeprüft als Grundlage für Preise, Fristen, Freigaben oder Rechtsfolgen nutzt, baut ein Risiko ein. Die belastbare Konstruktion sieht daher immer eine menschliche Bestätigung an den Stellen vor, an denen etwas Verbindliches entsteht.
Hinzu kommen zwei nüchterne Punkte. Datenschutz: KI-Funktionen verarbeiten Inhalte, unter Umständen bei Unterauftragnehmern und außerhalb der EU. Welche Daten in welche Modelle fließen, ob sie zum Training verwendet werden und wie lange sie gespeichert bleiben, gehört vor der Aktivierung geklärt und dokumentiert. Kosten: KI-Nutzung wird üblicherweise verbrauchsabhängig oder über Zusatzpakete abgerechnet, was eine ursprünglich planbare Lizenzrechnung variabel macht. Beides sollte in der Bewertung stehen, bevor eine Funktion breit eingeschaltet wird.
Der belastbarste Weg ist die REST-Schnittstelle. Über sie lassen sich Datensätze lesen, anlegen, ändern und löschen, Tabellen und Felder abfragen und je nach Umfang auch Strukturinformationen auswerten. Die Authentifizierung erfolgt über Token mit definierbarem Geltungsbereich, sodass ein Zugang gezielt auf eine Base und bestimmte Rechte begrenzt werden kann. Für die Anbindung eines Fachsystems, für ein Importskript oder für eine eigene Weboberfläche ist das der richtige Weg.
Ergänzend erlauben Webhooks den umgekehrten Fluss: Ein Ereignis in der Base wird an ein externes System gemeldet, oder ein externes System löst eine Automatisierung in Airtable aus. Damit entstehen ereignisgesteuerte Ketten, die deutlich effizienter sind als regelmäßiges Abfragen im Minutentakt. Zwei Hinweise aus der Praxis: Erstens gehören API-Zugriffe kontingentiert gedacht, weil Aufrufe je Zeiteinheit begrenzt sind — die konkreten Grenzen sind beim Anbieter zu prüfen. Zweitens sollten Token wie Passwörter behandelt werden: eng begrenzt, dokumentiert, rotierbar und niemals in einer Tabelle oder einem Skript im Klartext hinterlegt.
Für die meisten Anbindungen im Mittelstand ist keine Programmierung nötig. Integrationsplattformen wie Zapier, Make oder das quelloffene, auch selbst betreibbare n8n verbinden Airtable mit Hunderten von Diensten über vorgefertigte Bausteine. Das ist schnell, wartbar und für Fachabteilungen zugänglich. Der Preis dafür ist ein zusätzlicher Verarbeiter in der Kette — datenschutzrechtlich relevant, weil die Daten dort durchlaufen und teilweise zwischengespeichert werden. Für Organisationen mit hohen Souveränitätsanforderungen ist die selbst betriebene Variante einer solchen Plattform daher oft die klügere Wahl, weil sie den Datenfluss im eigenen Haus hält.
Auf Seiten der Standardintegrationen sind für den DACH-Mittelstand vor allem vier Bereiche relevant. Microsoft 365: Kalender- und Terminanbindung, Ablage von Anhängen, Benachrichtigungen in Teams, Übergabe von Daten an Excel für Analysen. Google Workspace: Kalender, Ablage, Tabellen, Formularzuflüsse. Kommunikation: Chatkanäle für Statusmeldungen und Freigabeanfragen sowie E-Mail als robuster gemeinsamer Nenner. Dokumentenerzeugung: Angebote, Bestätigungen, Prüfprotokolle oder Etiketten aus Datensätzen erzeugen, meist über eine Erweiterung oder einen angebundenen Dienst.
Eine Besonderheit ist die Sync-Funktion, mit der Daten aus einer Quelle in eine andere Base gespiegelt werden — aus einer anderen Base, einer geteilten Ansicht oder je nach Edition aus externen Quellen. Der Zieldatenbestand ist dabei lesend gebunden und wird nachgeführt. Das löst ein Kernproblem sauber: Stammdaten leben an einer Stelle und werden dort gepflegt, stehen aber in anderen Bases zur Verknüpfung bereit, ohne kopiert zu werden. Für den Aufbau einer mehrteiligen Landschaft ist das der wichtigste Baustein überhaupt.
Für das Berichtswesen gilt eine klare Empfehlung: Airtable kann verdichten, gruppieren und in Interfaces Kennzahlen darstellen, ist aber kein Business-Intelligence-Werkzeug. Sobald Auswertungen über mehrere Quellen, historische Zeitreihen, komplexe Kennzahlenlogik oder unternehmensweites Reporting gefordert sind, gehört die Analyse in ein dafür gebautes Werkzeug. Der übliche Weg führt über die Schnittstelle oder einen regelmäßigen Export in ein Auswertungssystem — häufig in dasselbe, das auch die übrigen Unternehmensdaten aufnimmt. Damit bleibt Airtable, was es gut kann: die operative Datenhaltung und Arbeitsoberfläche, nicht die Wahrheitsquelle für Controlling.
Gegen Excel und Google Sheets gewinnt Airtable dort, wo mehrere Menschen dieselben Daten strukturiert pflegen, Beziehungen zwischen Datensätzen bestehen und Ansichten je Rolle unterschiedlich aussehen sollen. Es verliert dort, wo gerechnet, modelliert und analysiert wird. Die häufigste sinnvolle Konstellation ist deshalb keine Ablösung, sondern eine Aufteilung: Datenhaltung in Airtable, Analyse in der Tabellenkalkulation.
Microsoft Lists ist die naheliegende Option für Organisationen, die vollständig in Microsoft 365 arbeiten. Es bietet strukturierte Listen mit Feldtypen, Ansichten und Formularen sowie Automatisierung über die Power-Plattform — und bringt entscheidend keinen weiteren Anbieter in die Verarbeitung. Der Funktionsumfang bei Beziehungen, Verdichtungen und gestalteten Oberflächen bleibt hinter Airtable zurück, dafür sind Identitätsverwaltung, Berechtigungen, Compliance und Vertragslage bereits geklärt. Dataverse als Datenschicht der Power-Plattform ist der schwerere, aber strategisch tragfähigere Weg: eine echte Unternehmensdatenbasis mit Rollenmodell, Geschäftsregeln und Anbindung an Fachanwendungen. Wer dorthin will, plant ein IT-Projekt und keine Abteilungslösung — dafür entsteht etwas, das dem Wachstum standhält.
Notion kommt von der Dokumentenseite. Seine Stärke ist die Verzahnung von Text, Wissen und leichten Datenbanken in einer sehr flexiblen Oberfläche. Wenn Dokumentation, Handbücher, Protokolle und Aufgaben zusammengehören, ist Notion oft die angenehmere Wahl. Bei anspruchsvoller Datenmodellierung, tiefer Verdichtung über Beziehungen und gestalteten Anwendungsoberflächen liegt Airtable vorn. Die Trennlinie lautet vereinfacht: Notion für schreibende Arbeit mit Struktur, Airtable für strukturierte Arbeit mit Text.
SmartSuite tritt am direktesten gegen Airtable an und positioniert sich als breiter aufgestellte Arbeitsmanagement-Plattform mit Datenbankkern, zahlreichen Ansichten und vorgefertigten Anwendungsvorlagen für ganze Geschäftsbereiche. Für Organisationen, die neben der Datenhaltung auch klassische Projekt- und Prozessfunktionen aus einer Hand wollen, ist das eine ernsthafte Alternative. Monday kommt aus der Projekt- und Arbeitsmanagementrichtung und ist stärker, wenn Aufgaben, Auslastung und Team-Reporting im Zentrum stehen; als flexible Datenplattform für Fachanwendungen bleibt es hinter einem echten Datenbankkern zurück. SeaTable schließlich ist die im DACH-Raum wichtigste Alternative mit deutschem Hintergrund: konzeptionell nahe an Airtable, verfügbar als in Deutschland betriebener Dienst und zusätzlich in einer selbst betreibbaren Variante — was die Datenschutz- und Souveränitätsdiskussion erheblich verkürzt.
Baserow ist eine quelloffene Plattform mit ähnlichem Grundkonzept: Tabellen mit typisierten Feldern, Verknüpfungen, Ansichten, Formulare, Automatisierung, Schnittstelle. Sie kann als gehosteter Dienst oder vollständig im eigenen Rechenzentrum betrieben werden. NocoDB geht einen anderen Weg und legt eine Airtable-artige Oberfläche über eine bestehende relationale Datenbank. Das ist besonders reizvoll, wenn im Unternehmen ohnehin ein Datenbankserver läuft und man dessen Inhalte für Fachanwender bedienbar machen möchte, ohne die Daten in eine Cloud zu verlagern.
Beide Wege bieten maximale Datenhoheit ohne Drittlandproblematik, verschieben aber Betrieb, Aktualisierung, Sicherung, Verfügbarkeit und Sicherheitspflege in die eigene Verantwortung. Der Funktionsumfang ist in einzelnen Bereichen schlanker, insbesondere bei gestalteten Oberflächen, KI-Bausteinen und dem Umfang fertiger Integrationen. Die belastbare Entscheidungsregel lautet: Wer eigene IT-Kapazität hat und Souveränität als harte Anforderung führt, findet hier eine sehr gute Lösung. Wer beides nicht hat, zahlt die Ersparnis bei den Lizenzen mit Betriebsaufwand und Risiko zurück.
Vor dem ersten Feld steht eine Frage: Welche Dinge gibt es in diesem Bereich, und wie hängen sie zusammen? Kunden, Aufträge, Positionen, Artikel, Termine, Mitarbeitende, Dokumente, Prüfungen. Jedes dieser Dinge wird eine Tabelle, jede Beziehung ein Verknüpfungsfeld. Diese Übung dauert bei einem überschaubaren Anwendungsfall eine bis zwei Stunden und ist die wirtschaftlichste Zeit im gesamten Projekt. Der typische Fehler ist die breite Tabelle: alles in einer Tabelle mit fünfzig Spalten, weil die Excel-Vorlage so aussah. Sie funktioniert bis zur ersten Auswertung und wird danach nie wieder sauber.
Drei Prüffragen helfen. Erstens: Wiederholt sich ein Wert in vielen Zeilen? Dann gehört er in eine eigene Tabelle und wird verknüpft. Zweitens: Gibt es Felder, die nur für einen Teil der Datensätze gefüllt sind? Dann handelt es sich wahrscheinlich um zwei verschiedene Dinge. Drittens: Muss man zählen, summieren oder das Neueste finden? Dann braucht es eine Verknüpfung mit Roll-up statt einer Handrechnung. Wer diese drei Fragen konsequent anwendet, kommt bei Fachanwendungen im Mittelstand fast immer zu einem tragfähigen Modell.
Der häufigste Betriebsschaden ist unspektakulär: Die Kollegin, die die Base gebaut hat, wechselt die Abteilung, und ein halbes Jahr später kann niemand mehr erklären, warum eine Automatisierung Mails verschickt. Deshalb braucht jede Lösung, die über einen Prototypen hinausgeht, eine benannte fachliche Verantwortung und eine minimale Dokumentation: Zweck, Datenmodell, Regeln, Zugänge, Schnittstellen, Ansprechpartner. Zwei Seiten reichen. Wichtig ist, dass sie außerhalb der Plattform liegen, damit sie auch dann verfügbar sind, wenn der Zugang fehlt.
Auf Organisationsebene bewährt sich ein leichter Rahmen statt eines Regelwerks: eine Liste der genehmigten Arbeitsbereiche mit Verantwortlichen, eine Vorgabe, welche Datenarten nicht in die Plattform gehören, eine Freigabepflicht für externe Teilen-Links, ein Register der Integrationen und eine feste Überprüfung im Jahresrhythmus. Diese fünf Punkte verhindern erfahrungsgemäß den größten Teil der Probleme, ohne die Geschwindigkeit zu nehmen, die den Reiz der Plattform ausmacht.
Es gibt klare Warnsignale, dass ein Anwendungsfall die Plattform verlassen sollte. Wenn Datenmengen so wachsen, dass Ansichten träge werden und Kapazitätsgrenzen in Sicht kommen. Wenn Transaktionssicherheit gefordert ist, also mehrere Änderungen zwingend gemeinsam gelingen oder gemeinsam scheitern müssen. Wenn gesetzliche Nachweispflichten greifen, etwa bei buchhalterisch relevanten Vorgängen mit Unveränderbarkeit und Aufbewahrungsfristen. Wenn die Logik in Skripten die Logik in der Konfiguration überwiegt. Und wenn viele gleichzeitige Nutzer mit widerstreitenden Änderungen arbeiten. Jedes dieser Signale allein ist noch kein Abbruchgrund, aber zwei zusammen sollten eine ehrliche Neubewertung auslösen.
Genau deshalb gehört die Exit-Strategie an den Anfang, nicht ans Ende. Praktisch bedeutet das drei Dinge. Erstens: regelmäßige, automatisierte Exporte der Daten in ein neutrales Format, gespeichert im eigenen Haus — nicht als Notfallmaßnahme, sondern als Routine. Zweitens: ein dokumentiertes Datenmodell, das eine Migration in ein anderes System überhaupt planbar macht; ohne es beginnt jeder Wechsel mit Reverse Engineering. Drittens: das Bewusstsein, dass Interfaces, Automatisierungen und Ansichten nicht migrierbar sind. Sie sind plattformspezifische Konfiguration und müssen im Zielsystem neu gebaut werden. Wer das einkalkuliert, trifft eine informierte Entscheidung; wer es verdrängt, erlebt den Wechsel als Projekt, das niemand beantragt hat.
In allen Fällen gilt dasselbe Profil: überschaubare Datenmengen, viele Merkmale je Datensatz, mehrere Beteiligte mit unterschiedlichem Blickwinkel, wiederkehrende Abläufe und ein hoher Anteil bisher unstrukturierter Information. Dazu kommt ein Faktor, der in Wirtschaftlichkeitsrechnungen selten auftaucht, in der Praxis aber entscheidet: Diese Lösungen entstehen dort, wo sie gebraucht werden. Die Fachabteilung baut ihre Anwendung selbst, sieht das Ergebnis in Tagen und kann es anpassen, sobald sich der Prozess ändert. Der Verzicht auf den Umweg über Anforderungsdokumente, Priorisierung und Entwicklungszyklen ist der eigentliche Wertbeitrag.
Ebenso deutlich ist die Kehrseite. Wo Geld gebucht, Ware bewegt, Lohn abgerechnet oder rechtlich Verbindliches dokumentiert wird, gehört die Führung in ein Fachsystem. Airtable kann dort ergänzend arbeiten — als Vorstufe, als Erfassungsoberfläche, als Übersicht, als Schaltstelle — aber nicht als System of Record. Diese Rollenzuweisung sauber zu treffen und auch auszusprechen, ist die wichtigste Aufgabe bei der Einführung.
Es gibt einen wiederkehrenden Punkt in erfolgreichen Airtable-Projekten, an dem der Erfolg selbst zum Problem wird. Die Lösung funktioniert, die Nachbarabteilung möchte mitmachen, der Datenbestand wächst, es kommen Sonderfälle hinzu, und plötzlich enthält die Base die Kernprozesse eines Bereichs. Ab diesem Moment stellen sich Fragen, die eine Abteilungslösung nicht beantworten kann: Was passiert bei Ausfall? Wer trägt die Verantwortung? Wie wird geprüft? Wie wird revisionssicher dokumentiert?
Unsere Empfehlung lautet, diesen Punkt vorab zu definieren statt ihn zu erleiden. Konkret: Schwellenwerte festlegen, bei deren Erreichen eine bewusste Entscheidung fällig ist — etwa Zahl der Nutzenden, Zahl der Datensätze, Kritikalität des Prozesses, Anteil personenbezogener Daten, Zahl der angebundenen Systeme. Wird ein Schwellenwert überschritten, gibt es drei legitime Antworten: die Lösung bewusst begrenzen, sie professionell in ein Fachsystem oder eine Plattform mit Unternehmensdatenschicht überführen, oder sie unter verschärfter Governance auf der bestehenden Plattform weiterbetreiben. Alle drei sind vertretbar. Nicht vertretbar ist, die Frage nicht zu stellen.
Die sichtbare Lizenzgebühr je Nutzer und Monat ist nur ein Teil der Rechnung. Belastbar wird eine Kalkulation erst mit vier weiteren Posten. Erstens die Nutzerzählung: Wie werden Personen gezählt, die nur lesen, nur kommentieren, nur ein Formular ausfüllen oder nur ein Interface nutzen? Diese Frage entscheidet bei breiter Nutzung mehr über die Rechnung als der Grundpreis und muss vorab beim Anbieter geklärt werden. Zweitens verbrauchsabhängige Bestandteile: Automatisierungsläufe, KI-Nutzung, Speicher für Anhänge, Schnittstellenaufrufe. Drittens Nebensysteme: eine Integrationsplattform, ein Dokumentenerzeuger, ein Auswertungswerkzeug. Viertens der interne Aufwand für Entwurf, Aufbau, Einweisung, Pflege und Aufräumen — der größte und regelmäßig unterschätzte Posten.
Hinzu kommt ein einmaliger, aber unvermeidbarer Block: die Compliance-Vorarbeit. Datenschutzprüfung, Eintrag in das Verzeichnis der Verarbeitungstätigkeiten, Vertragsprüfung, gegebenenfalls Abstimmung mit der Arbeitnehmervertretung, Festlegung von Löschfristen. Dieser Aufwand fällt bei jedem Cloud-Dienst an, wird aber bei niedrigschwelligen Werkzeugen fast immer vergessen — weil das Werkzeug so harmlos aussieht. Konkrete Preise nennen wir hier bewusst nicht; Konditionen und Modelle ändern sich und sind beim Anbieter zu prüfen.
Der zentrale Prüfpunkt ist die Frage, wo Daten gespeichert und verarbeitet werden. Der Anbieter betreibt seinen Dienst als Cloud-Angebot mit Infrastruktur, deren Standorte und Regionsoptionen produkt-, edition- und stichtagsabhängig sind. Ob eine Datenhaltung in der Europäischen Union möglich ist, für welche Datenarten sie gilt und an welche Edition sie gebunden ist, muss beim Anbieter konkret und schriftlich geprüft werden — pauschale Aussagen dazu sind unseriös. Wichtig ist zusätzlich die Unterscheidung zwischen der Speicherung von Inhaltsdaten und der Verarbeitung von Metadaten, Protokolldaten, Supportzugriffen und Diensten von Unterauftragnehmern, die abweichend geregelt sein können. Gerade KI-Funktionen führen hier häufig weitere Verarbeiter ein.
Da der Anbieter dem Recht eines Drittlandes unterliegt, ist der Drittlandtransfer gesondert zu betrachten. Rechtlich stützt sich die Übermittlung in der Regel auf die einschlägigen Angemessenheits- beziehungsweise Transfermechanismen und auf ergänzende Garantien im Vertragswerk. Grundlage jeder Nutzung ist ein Auftragsverarbeitungsvertrag mit dokumentierten technischen und organisatorischen Maßnahmen sowie einer nachvollziehbaren Liste der Unterauftragnehmer. Beides gehört in die Dokumentation und in das Verzeichnis der Verarbeitungstätigkeiten. Bei umfangreichen personenbezogenen Verarbeitungen — Bewerberdaten, Beschäftigtendaten, Kundendaten in großer Zahl — ist zusätzlich zu prüfen, ob eine Datenschutz-Folgenabschätzung erforderlich ist.
Ein weiterer Punkt verdient besondere Aufmerksamkeit, weil er in dieser Werkzeugklasse spezifisch ist: externe Freigabelinks. Geteilte Ansichten, öffentlich erreichbare Formulare und geteilte Interfaces machen Daten außerhalb der Anmeldung verfügbar. Sie sind ein legitimes und nützliches Mittel, brauchen aber eine Freigaberegel, eine Begründung und eine regelmäßige Überprüfung. Eine geteilte Ansicht, die vor zwei Jahren für einen Dienstleister erstellt wurde und noch aktiv ist, ist ein Datenschutzvorfall in Wartestellung.
Weil jede Änderung an einem Datensatz mit Zeitstempel und Urheber protokolliert wird, ist Airtable grundsätzlich geeignet, Verhalten und Leistung zu überwachen — unabhängig davon, ob das beabsichtigt ist. In Deutschland löst diese Eignung in Betrieben mit Betriebsrat die Mitbestimmung nach § 87 BetrVG aus. Der pragmatische Weg besteht darin, die Arbeitnehmervertretung früh einzubinden und in einer Vereinbarung festzuhalten, wofür Daten genutzt werden und wofür ausdrücklich nicht — insbesondere, dass keine individuelle Leistungsbewertung erfolgt. Für Österreich und die Schweiz gelten sinngemäß eigene Regelungen, die separat zu prüfen sind.
Auf der inhaltlichen Seite ist Datensparsamkeit die wirksamste Maßnahme. Weil das Anlegen eines Feldes so einfach ist, wachsen Bases ungebremst — und irgendwann enthält eine Projekttabelle Gesundheitsangaben, Gehaltsinformationen oder Vertragsdetails, die dort nie hätten landen dürfen. Eine kurze, verbindliche Inhaltsrichtlinie je Anwendungsfall verhindert das zuverlässiger als jede technische Maßnahme. Ergänzend braucht jede Lösung ein Löschkonzept: Wie lange bleiben Datensätze, wann werden Anhänge entfernt, wie wird mit dem Änderungsverlauf umgegangen, wie werden Bewerberdaten nach Abschluss eines Verfahrens beseitigt? Ohne diese Festlegungen entsteht ein Archiv, das niemand verantworten kann.
Wer aus strategischen oder regulatorischen Gründen einen europäischen Anbieter bevorzugt oder den Betrieb in eigener Hand behalten möchte, hat in dieser Werkzeugklasse ungewöhnlich gute Alternativen. Auf der europäischen Seite ist SeaTable aus Deutschland konzeptionell am nächsten an Airtable und sowohl als in Deutschland betriebener Dienst als auch selbst betreibbar verfügbar. Auf der quelloffenen Seite stehen Baserow mit ähnlichem Funktionsprinzip und NocoDB als Oberfläche über eine bestehende relationale Datenbank zur Verfügung. Alle drei lassen sich so betreiben, dass keine Daten in ein Drittland gelangen — was die Datenschutzdokumentation drastisch vereinfacht und die Diskussion über Transfermechanismen erübrigt.
Die nüchterne Abwägung sieht so aus: Selbst betriebene Lösungen bieten maximale Datenhoheit und ein planbares Kostenmodell ohne Nutzerpreise, verlagern aber Betrieb, Aktualisierung, Sicherung, Verfügbarkeit und Sicherheitspflege vollständig in die eigene Verantwortung. Für Organisationen ohne eigene IT-Kapazität ist das selten die günstigere Rechnung. Für solche mit vorhandener Infrastruktur, mit hohen Souveränitätsanforderungen oder mit besonders sensiblen Daten ist es häufig die richtige Wahl. Und für Organisationen, die vollständig in Microsoft 365 arbeiten, lohnt vor jeder Anbieterentscheidung der Blick, ob die dort enthaltenen Bausteine für den konkreten Anwendungsfall ausreichen — denn kein zusätzlicher Verarbeiter ist immer die einfachste Antwort.
