Notion, Airtable und Supabase lösen unterschiedliche Probleme. Dieser Artikel gibt dir konkrete Grenzwerte, echte Kosten und einen Entscheidungspfad, bevor du in sechs Monaten gegen ein Limit läufst.
Warum die Tool-Wahl teurer ist, als sie aussieht
Die meisten Teams wählen ihre Datenbank nicht, sie stolpern hinein. Notion ist eh schon da, also landet die Kundenliste dort. Oder Airtable sieht aus wie Excel mit Superkräften, also zieht die halbe Agentur um. Sechs Monate später liegen 40.000 Datensätze in einer Base, drei Leute bearbeiten gleichzeitig, und die API antwortet mit 429 Too Many Requests.
Die Entscheidung zwischen Airtable, Notion und Supabase ist keine Geschmacksfrage, sondern eine Architektur-Entscheidung. Dieser Artikel sortiert die drei danach, wofür sie tatsächlich gebaut wurden, gibt dir konkrete Grenzwerte und am Ende einen klaren Entscheidungspfad.
Was die drei Tools wirklich sind
Der häufigste Fehler ist, die drei als austauschbare Varianten derselben Sache zu sehen. Sie lösen unterschiedliche Probleme.
- Notion ist ein Dokumenten- und Wiki-Tool mit angebauter Datenbank-Ansicht. Jede Zeile ist in Wahrheit eine Seite. Stark für Wissensdatenbanken, Content-Kalender, Meeting-Notizen und leichtes Projekt-Tracking. Schwach, sobald echte relationale Integrität oder große Datenmengen ins Spiel kommen.
- Airtable ist ein Hybrid aus Tabelle und Datenbank. Verknüpfte Datensätze, Views, Formeln, Automationen. Gebaut für Operations-Teams, die strukturierte Daten brauchen, ohne SQL zu schreiben: Redaktionsplanung, CRM light, Inventar, Bewerber-Pipelines.
- Supabase ist eine echte Postgres-Datenbank mit automatisch generierter REST- und GraphQL-API, Auth, Storage und Realtime. Das ist ein Backend, kein fertiges Endnutzer-Tool. Jemand muss ein Frontend darauf bauen.
Kurzformel: Notion für Text, Airtable für Tabellen, die Menschen im Browser pflegen, Supabase für Daten, die Code liest und schreibt.
Die vier Fragen, die die Wahl entscheiden
Statt Feature-Listen zu vergleichen, beantworte vier Fragen. Sie führen fast immer zu einer eindeutigen Antwort.
- Wie viele Datensätze? Unter 5.000 ist alles entspannt. Ab 50.000 fällt Notion praktisch raus und Airtable wird teuer. Ab 100.000 gehört die Wahrheit in eine echte Datenbank.
- Wer schreibt die Daten? Menschen, die im Browser klicken, oder Code über eine API? Manuelle Pflege spricht für Airtable oder Notion. Automatischer Zu- und Abfluss über Skripte, Webhooks oder ein Produkt spricht für Supabase.
- Brauchst du eine eigene Oberfläche? Wenn Kunden oder eine App direkt auf die Daten zugreifen, brauchst du Supabase. Airtable und Notion sind interne Werkzeuge, keine Produkt-Backends.
- Wie kritisch sind Rechte und DSGVO? Feingranulare Zugriffsrechte pro Zeile (Row Level Security) gibt es nur bei Supabase. Airtable und Notion regeln Rechte auf Tabellen- oder Seiten-Ebene, nicht pro Datensatz.
Wo jedes Tool an die Wand fährt
Jedes der drei Tools hat eine harte Grenze, die man oft erst spürt, wenn es zu spät ist.
Airtable deckelt Datensätze pro Base: 1.000 im Gratis-Tarif, 50.000 im Team-Plan, 125.000 im Business-Plan. Die API erlaubt 5 Requests/Sekunde pro Base. Wer darüber liegt, bekommt 429 und muss Batching und Retry-Logik bauen. Für eine Sync-Pipeline, die alle paar Minuten tausende Zeilen abgleicht, ist das eine echte Bremse.
Notion ist noch enger: Die API liegt im Schnitt bei rund 3 Requests/Sekunde, Paginierung in 100er-Blöcken, und die Datenbanken werden bei mehreren tausend Einträgen spürbar träge. Relationale Integrität gibt es nicht, verknüpfte Seiten können ins Leere zeigen, ohne dass es jemand merkt.
Supabase hat keine dieser Limits, dafür eine andere Hürde: Ohne jemanden, der SQL und ein bisschen Frontend kann, bleibt es leer. Es gibt einen Table-Editor im Dashboard, aber kein Team pflegt darüber ernsthaft täglich Daten. Du tauschst Datensatz-Limits gegen Entwicklungsaufwand.
Was es real kostet
Rechne mit einem Team aus fünf Leuten, alle mit Schreibzugriff, Stand 2026.
- Notion: Der Plus-Tarif liegt bei rund 10 USD pro Person und Monat, also etwa 50 USD monatlich. Der Preis skaliert linear mit jedem Kopf.
- Airtable: Der Team-Plan kostet rund 20 USD pro Person und Monat (jährlich abgerechnet), macht rund 100 USD. Business startet bei etwa 45 USD pro Kopf. Auch hier zahlst du pro Sitz, nicht pro Datenmenge.
- Supabase: Der Pro-Tarif beginnt bei rund 25 USD pro Monat für das gesamte Projekt, unabhängig von der Teamgröße. Zugriffe und Nutzer sind praktisch unbegrenzt, du zahlst für Speicher und Rechenlast, nicht für Sitze.
Die Logik dahinter ist wichtiger als der Betrag: Airtable und Notion werden mit jedem neuen Kollegen teurer, Supabase mit jedem Gigabyte und jeder Last. Bei zwanzig Leuten dreht sich die Rechnung deutlich zugunsten von Supabase.
Der Entscheidungspfad
Setz die vier Fragen in Reihenfolge und du landest fast immer richtig:
- Greift eine App oder ein Kunde direkt auf die Daten zu, oder brauchst du Rechte pro Zeile? Dann Supabase, ohne Diskussion.
- Sind es überwiegend Texte, Wissen und Dokumente, die Menschen lesen? Dann Notion.
- Sind es strukturierte Tabellen, die dein Team im Browser pflegt, und bleibt ihr unter rund 50.000 Zeilen? Dann Airtable.
Häufig ist die beste Antwort eine Kombination, keine Entscheidung. Notion für Doku und Prozesse, Airtable als Bedien-Oberfläche fürs Tagesgeschäft, Supabase als Quelle der Wahrheit dahinter. Ein kleiner Sync-Job (etwa über n8n, Make oder ein eigenes Skript) hält Airtable und Supabase im Gleichstand: Menschen pflegen im vertrauten UI, die App liest aus Postgres.
Woran du merkst, dass du wechseln musst
Es gibt klare Signale, dass ein Tool aus seiner Rolle herausgewachsen ist:
- Deine Automationen laufen häufiger in Rate-Limits (
429) als sauber durch. - Du baust Workarounds, um Datensätze auf mehrere Bases oder Datenbanken zu verteilen, weil eine an ihr Limit stößt.
- Zwei Personen überschreiben sich gegenseitig, weil es keine echte Transaktionslogik gibt.
- Du exportierst regelmäßig nach CSV, um irgendwo anders damit zu rechnen.
Wenn zwei oder mehr davon zutreffen, ist die Frage nicht mehr ob, sondern wann. Der ehrliche Rat: Fang klein und pragmatisch an (Airtable oder Notion), aber plane die Migration nach Postgres von Anfang an mit, indem du saubere IDs und Feldstrukturen führst. Dann ist der Umzug später ein Skript und kein Neuanfang.