Perplexity baut eine eigene Datenbank mit KI-Agenten. Sollten Sie jetzt mehr Software selbst bauen?

Perplexity hat eine der provokantesten KI-Software-Geschichten des Jahres veröffentlicht.

Nach Angaben des Unternehmens entwickelten zwei Ingenieure gemeinsam mit Hunderten dauerhaft aktiven KI-Agenten den Kern von CobbleDB in zwei Monaten. Der Key-Value-Store ist auf Perplexitys eigene Websuche zugeschnitten und soll für diesen Pfad Amazon DynamoDB ersetzen. Perplexity berichtet außerdem von anwendungsspezifischen Verbesserungen, darunter eine etwa fünfmal niedrigere Latenz bei Batch-Lesezugriffen.

Das sind Unternehmensangaben und keine unabhängig geprüften Ergebnisse. Trotzdem ist der Fall relevant.

Die falsche Lehre liegt auf der Hand: „Wenn KI eine Datenbank bauen kann, sollten wir unsere SaaS- und Cloud-Dienste ebenfalls ersetzen.“

Die nützliche Lehre ist anspruchsvoller:

Wenn KI die Implementierung verbilligt, verändert sich Build versus Buy – Architektur- und Betriebsverantwortung verschwinden aber nicht.

Für Gründer, CTOs, Product Owner und Mittelständler ist diese Unterscheidung entscheidend. KI-Agenten können individuelle Software dort wirtschaftlich machen, wo sie bisher zu teuer erschien. Sie können aber genauso leicht Infrastruktur erzeugen, die das Unternehmen nie gebraucht hat und nicht zuverlässig betreiben kann.

Keine pauschale „Wir bauen es selbst“-Entscheidung

Perplexity kündigte keine Datenbank an, weil Datenbanken interessant sind.

Beschrieben wurde ein enger, hochvolumiger Workload mit messbarem Problem. Das Unternehmen kontrolliert das Zugriffsmuster, kann gezielt dafür optimieren und arbeitet in einer Größenordnung, in der sich Latenz und Cloud-Kosten stark summieren. Damit entsteht ein plausibler Business Case für spezialisierte Infrastruktur.

Die Reihenfolge ist wichtig:

1. Ein produktiver Workload existierte bereits.
2. Verhalten und Kosten waren beobachtbar.
3. Das Team konnte eine begrenzte technische Schnittstelle identifizieren.
4. Die Speziallösung hatte messbare Ziele.
5. Der erwartete Vorteil war groß genug, um eigene Verantwortung zu rechtfertigen.

Das unterscheidet sich von einer Eigenentwicklung, die nur deshalb beginnt, weil ein Agent schnell einen überzeugenden Prototyp erzeugt.

Die meisten Unternehmen sollten Standardfunktionen weiterhin einkaufen. Authentifizierung, Zahlungsabwicklung, E-Mail-Versand, Object Storage, Observability und Datenbanken sind als Managed Service meist sicherer und günstiger – besonders bei üblichen Anforderungen und moderater Skalierung.

Eigenentwicklung wird interessant, wenn ein Standardprodukt eine geschäftlich relevante Grenze für etwas setzt, das das Unternehmen differenziert.

KI verändert einen Teil der Rechnung

Eine klassische Build-or-Buy-Entscheidung berücksichtigt Implementierungskosten, Lizenz- oder Nutzungskosten, Integration, Opportunitätskosten, Wartung und Betriebsrisiko.

KI-Agenten können den Implementierungsaufwand senken. Sie erkunden Alternativen, erstellen Experimente, schreiben wiederkehrenden Code, erzeugen Tests, untersuchen Fehler und bearbeiten Aufgaben parallel. Dadurch kann eine individuelle Lösung früher wirtschaftlich plausibel werden.

Doch die Implementierung war nie die gesamte Rechnung.

Eine Komponente, die in zwei Monaten entsteht, kann zehn Jahre produktiv bleiben. In dieser Zeit muss jemand sie verstehen, aktualisieren, absichern, überwachen, wiederherstellen, dokumentieren und weiterentwickeln.

Die neue Frage lautet nicht:

Kann ein Agent das bauen?

Sondern:

Rechtfertigt die günstigere Implementierung die Verantwortung, die wir uns damit dauerhaft schaffen?

Das ist eine Produkt- und Architekturentscheidung, keine Prompt-Engineering-Entscheidung.

Generierter Code ist nicht die knappe Ressource

„Zwei Ingenieure und Hunderte Agenten“ klingt nach einem extremen Produktivitätsverhältnis. Die knappe menschliche Arbeit lag jedoch vermutlich nicht im Tippen von Datenbankcode. Sie lag in der Definition des Workloads, der Architekturwahl, der Aufgabenzerlegung, der Validierung, dem Auflösen von Widersprüchen, der Risikoprüfung und der Entscheidung über Produktionsreife.

Hunderte Agenten erzeugen neben Output auch Koordinationsprobleme. Parallele Änderungen können kollidieren. Tests können falsche Annahmen bestätigen. Lokale Optimierungen können Systemeigenschaften beschädigen. Plausible Implementierungen können unterschiedliche Invarianten voraussetzen.

Bei kritischer Infrastruktur konzentriert sich menschliche Verantwortung auf Fragen wie:

• Welche Konsistenzgarantien braucht das Produkt wirklich?
• Welche Fehlerbilder sind akzeptabel?
• Wie werden Daten migriert, geprüft und zurückgerollt?
• Was geschieht bei partiellen Netzwerk- oder Dienstausfällen?
• Welche Metriken belegen eine reale Verbesserung statt eines schnelleren Benchmarks?
• Wer kann den Rollout stoppen?
• Wer besitzt das System, wenn das ursprüngliche Team weiterzieht?

KI vervielfacht Implementierungskapazität. Gleichzeitig wächst die Menge der Änderungen, die geprüft werden muss. Architektur, Verifikation und Betriebsdesign werden gerade deshalb zu Engpässen, weil Code billiger wird.

Ein praktischer Build-or-Buy-Test

Vor der Eigenentwicklung eines Ersatzes für einen bestehenden Dienst sollten fünf Fragen beantwortet sein.

1. Differenziert der Workload das Geschäft?

Eigenentwicklung ist sinnvoll, wenn die Komponente eine für Kunden wertvolle Fähigkeit oder eine wesentliche Geschäftsgrenze beeinflusst.

Bei Standardanforderungen bleibt ein reifer Managed Service meist wirtschaftlicher. Ein weiteres eigenes Identity-System, eine Queue oder ein Scheduler schafft wenig Wert, nur weil KI schnell eine erste Version erzeugen kann.

2. Ist das Problem gemessen?

„Die Rechnung wirkt hoch“ und „der Dienst fühlt sich langsam an“ reichen nicht.

Messen Sie Latenzverteilungen, Fehlerraten, Durchsatz, Stückkosten, Vorfälle, Engineering-Aufwand und Geschäftsauswirkungen. Vergleichen Sie die Eigenlösung mit realistischen Alternativen: Tuning, Caching, ein anderer Tarif oder ein anderer Anbieter.

3. Lässt sich die Grenze isolieren?

Ein guter Kandidat hat eine klare Schnittstelle und einen Migrationsweg.

Das neue System sollte hinter einer Abstraktion eingeführt werden können. Datenverkehr sollte sich spiegeln, Ergebnisse sollten vergleichbar und ein Rückweg möglich sein. Eine Big-Bang-Migration kann den vermeintlichen Geschwindigkeitsgewinn durch enormes Geschäftsrisiko aufzehren.

4. Können Sie das System um 03:00 Uhr betreiben?

Das Entwicklungsbudget ist noch kein Betriebsmodell.

Eigene Infrastruktur braucht Monitoring, Backups, Kapazitätsplanung, Incident Response, Security-Verantwortung, Upgrade-Pfade, Disaster Recovery und Dokumentation. Wenn nur die ursprünglichen Entwickler Fehler diagnostizieren können, ist keine Plattform entstanden, sondern eine personelle Abhängigkeit.

5. Wann brechen Sie ab?

Definieren Sie Abbruchkriterien vor dem Start.

Stoppen Sie, wenn Vorteile unter realistischer Last verschwinden, das Migrationsrisiko den Nutzen übersteigt, der Betrieb zu aufwendig wird, die Managed-Alternative sich verbessert oder die erwartete Ersparnis eine Gesamtkostenrechnung nicht übersteht.

KI macht es billig, weiteren Code zu produzieren. Genau deshalb werden klare Stop-Kriterien wichtiger.

Mit einer begrenzten Herausforderung starten

Der sicherste Test für eine veränderte Build-or-Buy-Entscheidung ist nicht der sofortige Ersatz einer kritischen Plattform.

Wählen Sie eine teure oder einschränkende Schnittstelle. Entwickeln Sie einen repräsentativen Prototyp anhand realer Workload-Daten und Akzeptanzkriterien. Betreiben Sie ihn zunächst parallel. Messen Sie Korrektheit, Latenz, Kosten und Betriebsaufwand. Testen Sie Ausfälle und Rollbacks, nicht nur den Happy Path.

In einer Geschäftsanwendung kann das eine komplexe Preisberechnung, eine Dokumentenpipeline, ein Planungssystem, eine Legacy-Integration oder ein Reporting-Workload sein. Solche Bereiche eignen sich häufig besser als Standardinfrastruktur, weil sie unternehmensspezifisches Wissen enthalten.

Das Ziel ist nicht der Beweis, dass Agenten viel Code erzeugen. Das Ziel ist die Frage, ob individuelle Software die Wirtschaftlichkeit oder die Leistungsfähigkeit des Produkts verbessert.

Was Mittelständler mitnehmen sollten

Die meisten deutschen Unternehmen betreiben nicht den Such-Workload von Perplexity. Sie sollten dessen Infrastrukturentscheidung nicht kopieren.

Sie können aber die Entscheidungsdisziplin übernehmen:

• Optimieren Sie für einen realen Workload, nicht für einen Technologietrend.
• Begrenzen Sie das Problem so, dass es messbar bleibt.
• Behandeln Sie KI-Geschwindigkeit als Eingangsgröße, nicht als Business Case.
• Entwerfen Sie Migration, Monitoring und Rollback vor dem Produktivwechsel.
• Messen Sie die Gesamtkosten einschließlich Review und Betrieb.
• Lassen Sie Architektur und Release-Entscheidungen in menschlicher Verantwortung.

KI-gestützte Entwicklung kann maßgeschneiderte Systeme zugänglicher machen. Das ist wertvoll für Unternehmen, deren Abläufe nicht in Standardsoftware passen oder deren Wettbewerbsvorteil in einem spezialisierten Prozess liegt.

Doch eigener Code bleibt ein Vermögenswert mit angehängter Verpflichtung. Jede Zeile muss später verstanden, betrieben oder stillgelegt werden.

Der CobbleDB-Fall bedeutet nicht, dass jedes Team mehr selbst bauen sollte. Er bedeutet, dass Teams neu prüfen können, was sich zu bauen lohnt – solange sie ehrlich berücksichtigen, was nach dem Schreiben des Codes beginnt.

Genau dort zahlt sich architekturorientierte Entwicklung aus.