Einblicke
Eine Datenbank, die mitwächst
Mehr Nutzer kommen. Das ist erfreulich, wirft aber eine Frage auf: Wie lange reicht die bisherige Datenbank? Authrim bereitet neuen Kontospeicher vor, bevor er gebraucht wird. So muss Wachstum nicht mit einem Migrationsprojekt beginnen.
Mehr Speicher, bevor Daten umziehen müssen
Cloudflare D1, die von Authrim verwendete Datenbank, hat eine Größenbegrenzung pro Datenbank: 500 MB im Free-Tarif und 10 GB im Paid-Tarif. Wachsen Nutzerzahl und Datenbestand, wird irgendwann weiterer Speicher nötig.
Authrim verteilt Konten von Anfang an auf mehrere Datenbanken. Wenn mehr Kapazität gebraucht wird, müssen deshalb nicht alle vorhandenen Konten umziehen. Jede dieser Speichereinheiten nennen wir einen Shard.
Vorhandene Konten bleiben, wo sie sind. Für neue Konten kommen weitere Speicherorte hinzu. Das ist der Grundgedanke hinter der Erweiterung des Kontospeichers.
Daten wachsen unterschiedlich schnell
Authrim speichert Mandanteneinstellungen wie OAuth-Clients und Regeln, Konten und personenbezogene Daten sowie die Suchindizes zum Auffinden eines Kontos über seine E-Mail-Adresse getrennt.
Mehr Nutzer bedeuten nicht, dass alle Datenbanken zugleich wachsen müssen. Kontospeicher und Suchindizes haben unterschiedliche Datensatzmengen und Wachstumsraten. Kapazität kommt dort hinzu, wo sie gebraucht wird.
Wie viele Konten passen noch hinein?
Ein neues Konto wird einem Shard zugewiesen, der für seinen Mandanten verfügbar ist. Bevorzugt werden funktionsfähige Shards, deren Kontozahl im Verhältnis zum Zielwert niedriger ist.
Entscheidend ist nicht die belegte Festplattenkapazität, sondern wie viele Konten bis zum eingestellten Zielwert noch aufgenommen werden können. Bei einem Ziel von 100.000 Konten hilft ein Rest von etwa 20.000 dabei zu entscheiden, wann der nächste Speicherort vorbereitet werden sollte.
Wenn die verfügbaren Shards nur noch wenig Spielraum bieten, wird eine vorbereitete Reserve zugeteilt. Das gilt sowohl für gemeinsam genutzte Shards mehrerer Mandanten als auch für exklusive Shards eines einzelnen Mandanten.
Gemeinsam genutzter Speicher
Exklusiver Speicher
Gemeinsamer und exklusiver Speicher
Was im Alltag entfällt
Ist die automatische Bereitstellung eingerichtet, muss der Betreiber nicht bei jedem Wachstum eine Datenbank anlegen, Tabellen vorbereiten und einen neuen Speicherort für Registrierungen anbinden. Auch ein neuer Migrationsplan für bestehende Konten ist nicht jedes Mal nötig.
Der Betreiber prüft, ob die Bereitstellung vorankommt, Fehler sichtbar sind und Nutzung sowie Kosten im erwarteten Rahmen bleiben. Berechtigungsprobleme und Dienstlimits erfordern weiterhin Aufmerksamkeit. Die Vorbereitung des nächsten Speicherorts übernimmt Authrim.
Der freie Platz von heute reicht als Maßstab nicht
Bei 20.000 freien Kontoplätzen hat ein Dienst mit 100 neuen Konten pro Tag viel mehr Vorlauf als einer mit 10.000 pro Stunde.
Authrim schätzt den künftigen Bedarf deshalb aus aktuellen Belegungen und jüngsten Registrierungsraten. Die Prognose umfasst Kontospeicher und Suchindizes. Eine zeitgesteuerte Aufgabe läuft jede Minute; die Kontoprognose wird zusätzlich nach Zuweisungen aktualisiert.
Shards, die gerade angelegt werden, fließen bereits in die Schätzung ein. Wenn mehrere Prozesse denselben Engpass erkennen, soll nicht jeder eine zusätzliche unnötige Datenbank erstellen.
Von der Anlage bis zur Nutzung
Reicht die Reserve nicht aus, erstellt Authrim D1-Datenbanken über die Cloudflare-Verwaltungs-API. Es legt Tabellen an, richtet Worker-Zugriffe ein und verteilt die neuen Speicherorte. Erst nach erfolgreichen Lese- und Schreibprüfungen erhält eine Datenbank neue Konten.
Die automatische Bereitstellung muss aktiviert sein. Für D1 und Workers sind getrennte API-Tokens einzurichten. Ist die automatische Ausführung nicht verfügbar, führt ein Betreiber die Arbeit mit dem Setup-Werkzeug weiter.
Der Fortschritt wird während der Anlage gespeichert. Nach einem vorübergehenden Verbindungsfehler kann der Vorgang von dort aus wiederholt werden. Fehlende Berechtigungen oder Ressourcenlimits muss ein Betreiber beheben, bevor es weitergeht.
Wenn die Vorbereitung zu langsam ist und keine Kontoplätze mehr frei sind, müssen neue Registrierungen gegebenenfalls wiederholt werden. Vorausschauende Bereitstellung soll diese Wartezeit verringern.
Über Datenumzüge entscheidet der Betreiber
Kapazität ergänzen und vorhandene Daten verschieben sind getrennte Vorgänge. Soll ein Mandant etwa von einem gemeinsamen in einen exklusiven Shard wechseln, müssen auch die bestehenden Daten kopiert werden.
Der Betreiber entscheidet, ob die Migration beginnt. Nach der Freigabe übernimmt Authrim Synchronisierung, Prüfung und Umschaltung.
Unterstützt wird derzeit der Wechsel von gemeinsamem zu exklusivem Speicher. Der Rückweg und eine automatische gleichmäßige Neuverteilung bestehender Konten sind nicht implementiert.
Auch das Löschen eines ausgemusterten Shards erfordert eine Freigabe. Wachstum allein löst weder das Verschieben noch das Löschen vorhandener Daten aus.
Was gemessen wurde
In einem Test im Juli 2026 mit 200.000 Konten belegten Core etwa 208 MB, PII etwa 238 MB und Lookup etwa 426 MB. Jeder Bereich lag unter 5 % des Limits von 10 GB pro Datenbank im Paid-Tarif. Der tatsächliche Bedarf hängt von Attributen und Indizes ab.
Der voreingestellte Zielwert liegt bei 100.000 Konten pro Shard. So bleibt Zeit für die nächste Bereitstellung, statt die Datenbank bis an ihre physische Grenze zu füllen.
Authrim ist noch vor Version 1.0. Langjährige Betriebserfahrung in großem Maßstab muss erst entstehen. Eine Speichermessung mit 200.000 Testkonten ist etwas anderes als der tägliche Betrieb eines Dienstes für Millionen Menschen.
Wachsen mit weniger Migrationsplanung
Ein kleiner Dienst braucht nicht vom ersten Tag an eine große Infrastruktur. Er kann mit wenigen Shards beginnen und bei steigenden Registrierungen Speicherorte ergänzen. Authrim bringt die Vorbereitung und die dafür nötigen Abläufe mit.
Wenn mehr Nutzer kommen, soll ein Datenbankumzug nicht die erste Aufgabe auf der Liste werden. Weniger Arbeit daran bedeutet mehr Zeit für den Dienst selbst.
Speichermessung vom 30. Juli 2026 mit 200.000 Testkonten. MB bezeichnet dezimale Einheiten. Die D1-Kapazitätsgrenzen stehen in der Cloudflare-Dokumentation.