Am 14. September 2026 stellte Perplexity CobbleDB vor, einen eigenen verteilten Key-Value-Hot-Store für seine KI-Suche. Das System liefert vorbereitete Textpassagen und Vektor-Embeddings, die bei Suchanfragen wiederholt in Batches abgerufen werden. Perplexity meldet dabei eine mediane Latenz von 5,60 Millisekunden statt zuvor 31,4 Millisekunden mit DynamoDB.
CobbleDB ersetzt DynamoDB in einem Teil der Suchbereitstellung – nicht als pauschaler Austausch für jede Datenbankaufgabe bei Perplexity. Der Ansatz ist bewusst spezialisiert: Die Datenbank soll einen genau umrissenen, leseintensiven Pfad beschleunigen, statt Transaktionen und beliebige Anwendungsszenarien abzudecken.
Perplexity baut CobbleDB für einen klar begrenzten Suchpfad
CobbleDB speichert gehashte Seitenkennungen als Schlüssel. Die zugehörigen Werte enthalten bereits zerlegte Textpassagen und für jedes Fragment berechnete Vektor-Embeddings. Eine Suchanfrage ruft typischerweise rund 100 bis 120 Seitenkennungen ab, die in kleinere Batches aufgeteilt werden.
Diese Vorbereitung ist der entscheidende Punkt: CobbleDB muss die Dokumente nicht erst während der Anfrage verarbeiten. Es liest bereits strukturierte Datensätze aus einem auf schnelle Batch-Zugriffe zugeschnittenen Hot-Store.
Der Kern umfasst laut Perplexity rund 40.000 Zeilen Rust. Auf den Datenknoten übernimmt RocksDB die eingebettete Key-Value-Speicherung. Häufig benötigte Datensätze kommen aus dem Arbeitsspeicher, nicht im Cache liegende Werte vom lokalen NVMe-Speicher. Jede Partition besitzt drei Replikate auf drei verschiedenen Knoten.
Die gemeldeten Latenzgewinne sind groß – aber kein kontrollierter Direktvergleich
Perplexity verglich Produktionsmessungen aus der Zeit vor und nach der Migration. Die Werte wurden dabei nicht mit identischem Live-Traffic gleichzeitig gegen beide Systeme erhoben. Für die Einordnung ist das wichtig: Die Zahlen beschreiben einen beobachteten Vorher-nachher-Unterschied, keinen kontrollierten A/B-Test.
| Messwert | DynamoDB vor der Umstellung | CobbleDB nach der Umstellung |
| Mediane Batch-Latenz | 31,4 ms | 5,60 ms |
| p90-Latenz | 56,7 ms | 9,77 ms |
| p99-Latenz | 123 ms | 24,2 ms |
Aus den beiden Medianwerten ergibt sich eine Reduktion um rund 82,2 Prozent. Die Messungen fanden bei ungefähr 200.000 Anfragen pro Sekunde statt. In einem späteren Lasttest erreichte CobbleDB laut Perplexity bis zu 500.000 Anfragen pro Sekunde, bevor die Leistung nachließ. Das ist ein Lasttestergebnis und keine Angabe zum dauerhaft laufenden Produktionsverkehr.
So teilen Pillar, Lorry und CobbleDB die Arbeit auf
Perplexitys Architektur trennt dauerhaften Dokumentzustand, Aktualisierungstransport und schnelle Bereitstellung. Dadurch muss der Speicher für Suchanfragen nicht zugleich die gesamte Dokumentverarbeitung übernehmen.
| Komponente | Aufgabe | Eingesetzte Technologie |
| Pillar | Speichert versionierte Dokumentzustände mit Metadaten, Textfragmenten und Embeddings | YTsaurus auf HDD-Speicher |
| Lorry | Erstellt partitionsbezogene Batches und übergibt sie an CobbleDB | Amazon S3 als Datenebene |
| CobbleDB | Nimmt vorbereitete Datensätze auf und liefert sie bei Suchanfragen aus | RocksDB, Arbeitsspeicher und lokales NVMe |
Pillar bestimmt, welche Seitenbestände exportiert werden. Lorry liest die Exportdaten aus einer dauerhaften, partitionsausgerichteten Warteschlange, erzeugt Batch-Dateien und registriert sie bei CobbleDB. Die Replikate holen diese Dateien unabhängig voneinander ab und wenden sie in zeitlicher Reihenfolge an.
Bei einer Anfrage hasht ein zustandsloser Router die Seitenkennungen, gruppiert sie nach Partition und verteilt die Zugriffe parallel. Bevorzugt wird ein Replikat in derselben Verfügbarkeitszone. Wenn ein Lesezugriff zu langsam ist, kann eine weitere Replik angesprochen werden. Für die Batch-Abfragen nutzt CobbleDB RocksDB MultiGet.
Hunderte Coding-Agenten halfen – Menschen behielten die Kontrolle
CobbleDB entstand laut Perplexity in ungefähr zwei Monaten mit zwei menschlichen Entwicklern und Hunderten dauerhaft verfügbaren Coding-Agenten. Die Agenten unterstützten unter anderem bei Code-Inspektionen, Tests, Fehlerbehebungen, Dokumentation und der Pflege des Projektkontexts.
Die Architektur legten weiterhin Menschen fest. Sie prüften folgenreiche Änderungen und autorisierten den Betrieb in der Produktion. CobbleDB ist damit ein Beispiel für stark KI-unterstützte Softwareentwicklung, aber nicht für eine vollständig autonome Datenbankentwicklung oder -verwaltung.
Der Preis der Geschwindigkeit ist eigener Betriebsaufwand
Perplexity schätzt die Kosten der Speicherschicht in seinem internen Modell bei allen ausgewerteten Commitment-Stufen auf mindestens 20 Prozent unter denen von DynamoDB. In dieser Schätzung sind die Kosten für Entwicklung und Wartung des eigenen Datenspeichers nicht enthalten.
Das ist der zentrale Trade-off. Ein verwalteter Dienst nimmt dem Betreiber einen Teil des Datenbankbetriebs ab. Bei CobbleDB kontrolliert Perplexity dagegen Partitionierung, Cache-Zuteilung, Routing und Replikatauswahl selbst – muss aber auch die Infrastruktur betreiben und auf Fehler reagieren.
Für den beschriebenen Hot-Store-Pfad benötigt CobbleDB weder Transaktionen noch synchronisierte Replikate. Perplexity akzeptiert eine kurze Verzögerung zwischen dem Schreiben eines Dokuments und seiner Lesbarkeit. Das passt zu vorbereiteten Suchdaten, wäre aber nicht automatisch die passende Wahl für Anwendungen, die starke Konsistenz oder komplexe Transaktionen verlangen.
Perplexity plant eine Open-Source-Veröffentlichung
Perplexity plant, CobbleDB zu veröffentlichen, damit auch andere Teams mit KI-nativen Suchsystemen den Speichertyp nutzen können. Das Unternehmen beschreibt das Projekt damit als eine spezialisierte Infrastruktur für vorbereitete Suchdaten – nicht als Ersatz für jede Art von Datenbank.
