Notion gehört zu den besten Orten, an denen ein Team schreibt, plant und sein Wissen teilt. An seine Grenzen kommt es, wenn deine Informationen keine Sammlung von Seiten mehr sind, sondern ein Netz aus verknüpften Datensätzen. Kunden haben Bestellungen, aus Bestellungen werden Rechnungen, und Rechnungen fließen in Projekte ein. Verbringt dein Team mehr Zeit damit, Relationen und Rollups zu pflegen, als mit den Daten darin zu arbeiten, ist die Lösung klar: Zieh deine operativen Daten in eine relationale Datenbank um, die genau dafür gemacht ist. Notion behältst du für das, was es am besten kann, nämlich Schreiben.
Notion gehört das leere Blatt
Irgendwo in deinem Unternehmen liegt eine Notion-Seite mit der Onboarding-Checkliste, auf die alle schwören. Wie CNBC in seinem diesjährigen Disruptor-50-Ranking berichtet, hat Notion mit seinem modularen Ansatz über 100 Millionen Nutzer und mehr als die Hälfte der Fortune-500-Unternehmen überzeugt. CEO Ivan Zhao vergleicht diesen Ansatz mit Lego-Steinen für die Arbeit.
Der Reiz liegt auf der Hand. Ein Wiki, ein Meeting-Protokoll, eine Produkt-Roadmap und ein Content-Kalender starten alle als Text. Notion macht es leicht, diesen Text zu strukturieren, zu verlinken und zu teilen. Auch einfache Listen meistern seine Datenbanken gut, etwa eine Recruiting-Pipeline, eine Leseliste oder ein Sprint-Board mit einer Handvoll Eigenschaften.
Verlinkte Seiten sind keine verknüpften Datensätze
Hier liegt der Unterschied, der entscheidet, ob Notion mit dir Schritt hält. Jede Zeile in einer Notion-Datenbank ist eine Seite, und eine Relation verbindet eine Seite mit einer anderen. Für Wissen funktioniert das wunderbar, denn dort ist ein Link zwischen zwei Dokumenten einfach praktisch.
Operative Daten ticken anders. In einem CRM, einer Lagerverwaltung oder einer Projektabrechnung ist die Beziehung das Geschäft selbst. Welcher Kunde hat welche Bestellung? Was passiert mit den Positionen, wenn du eine Bestellung stornierst? Wer darf welchen Datensatz sehen? Diese Regeln gehören ins Datenmodell. Sie haben nichts in einer Seiteneigenschaft verloren, an deren Pflege jemand denken muss.
Notions eigene Dokumentation zieht die Grenze
Notion spricht erfrischend offen darüber, wo seine Datenbanken langsamer werden. Laut dem Hilfecenter fasst jede Datenbank bis zu 250.000 Zeilen. Außerdem rechnet eine Formel länger, wenn sie auf anderen Formeln aufbaut, die wiederum auf Rollups beruhen. Auch für Relationen in beide Richtungen nennt Notion eine Grenze: Verweist eine verknüpfte Datenbank 10.000-mal auf dieselbe Seite, tauchen neue Verweise auf der anderen Seite nicht mehr auf.
Für ein Team-Wiki spielt keine dieser Grenzen eine Rolle. Für einen wachsenden Kundenstamm dagegen umso mehr, denn ein einziger Großkunde sammelt schnell Tausende verknüpfte Bestellungen, Tickets und Rechnungen. Teams, die ihr operatives Geschäft in Notion aufgebaut haben, erwischt das oft kalt. Die Struktur hielt perfekt, bis das Unternehmen an genau diese Grenzen herangewachsen ist.
Aus Workarounds wird ein Problem mit der Datenqualität
Werden Relationen langsam oder unzuverlässig, improvisieren Teams. Sie tippen einen Kundennamen in ein Textfeld, statt ihn zu verknüpfen. Sie duplizieren eine Datenbank für jedes Team oder tragen Summen von Hand ein, weil ein Rollup zu lange lädt. Jede dieser Abkürzungen schafft eine zweite Version der Wahrheit.
Das kostet mehr, als es scheint. Tadhg Nagle, Thomas Redman und David Sammon haben in einer Studie für die Harvard Business Review die Datenqualität in Unternehmen untersucht. Nur drei Prozent der Werte erreichten den Maßstab, den die Manager selbst als akzeptabel festgelegt hatten. Fast die Hälfte der neu angelegten Datensätze enthielt mindestens einen kritischen Fehler. Doppelte, von Hand gepflegte Daten sind genau der Nährboden für solche Fehler.
Beziehungen gehören ins Datenmodell, nicht obendrauf
Hier zahlt sich ein relationales Fundament aus. Ninox ist eine AI-native Low-Code-Plattform, die von Grund auf auf Tabellen und Verknüpfungen aufbaut. Kunden mit Bestellungen und Bestellungen mit Rechnungen zu verbinden, ist bei Ninox der Ausgangspunkt. Du schraubst diese Verbindungen nicht nachträglich an.
In der Praxis wird das schnell konkret. Du verknüpfst Tabellen einmal und bearbeitest verknüpfte Datensätze direkt im Kundendatensatz, mit einem eingebetteten Formular statt ständiger Seitenwechsel. Legst du die Verknüpfung von Positionen zu Bestellungen als Untertabelle an, löschst du mit einer Bestellung auch ihre Positionen. So sammeln sich keine verwaisten Datensätze an. Eindeutige Felder stoppen Duplikate schon bei der Eingabe. Berechtigungen pro Datensatz legen fest, wer welchen Datensatz lesen, bearbeiten, anlegen oder löschen darf, und der Server setzt sie durch. Jede Tabelle fasst rund zehn Millionen Datensätze, und indizierte Felder halten häufige Filter auch in wachsenden Tabellen schnell.
Weil Ninox von Anfang an AI-native ist, beschreibst du das System, das du brauchst, in einfacher Sprache. Du bekommst einen funktionierenden Startpunkt mit Tabellen, Feldern und Logik und formst ihn dann selbst weiter.
Nichts davon heißt, dass du Notion verlassen musst. Viele Teams behalten ihr Wiki in Notion und steuern ihr operatives Geschäft auf einer Low-Code-Plattform, die für relationale Daten gemacht ist. Am schnellsten siehst du den Unterschied, wenn du deine chaotischste Notion-Datenbank auf Herz und Nieren prüfst. Exportier sie als CSV, importier sie in Ninox und verknüpf sie mit den Tabellen, zu denen sie schon immer gehört hat.
Teams erstellen ihre Datensysteme selbst, und das ist das neue Normal
Immer mehr Unternehmen erstellen die Software für ihr operatives Geschäft selbst, statt sich nach der Software anderer zu richten. Gartner prognostiziert, dass der Markt für Low-Code-Entwicklungstechnologien bis 2029 auf 58,2 Milliarden US-Dollar wächst, mit 14,1 Prozent pro Jahr. Am meisten profitieren die Teams, die sich für eine Low-Code-Plattform mit echtem Datenmodell entscheiden, bevor ihre Workarounds zur Gewohnheit werden.
Mach den nächsten Schritt.
