KI-native Anwendungen benötigen operative Daten und Analysen, die zusammenleben – hier erfahren Sie, wie Teams die Barriere beseitigen.
von Amey Banarse und Madelyn Mullen
In führenden Technologieunternehmen, die KI-native Apps entwickeln, ist die primäre Einschränkung nicht mehr die Modellfähigkeit, sondern die zugrunde liegende Datenarchitektur, insbesondere die Datenpipelines. Die Anforderungen von KI-Systemen an den Zugriff auf Echtzeit-Kontext und zustandsbehaftete Daten für Agenten sowie die geringen Grenzkosten für eine schnelle, experimentelle Entwicklung haben den kritischen Fehler in traditionellen, getrennten Datenarchitekturen aufgedeckt.
Operative Workloads laufen typischerweise auf Cloud-Transaktionsdatenbanken (z. B. verwaltete Postgres/MySQL-Engines), während Analysen, ML-Pipelines und Feature Engineering im Lakehouse angesiedelt sind. Die Synchronisierung zwischen diesen Ebenen beruht auf einem komplexen Netz aus CDC-Pipelines, ETL/ELT-Jobs und Reverse-ETL-Frameworks. Dies führt zu systemischen Ineffizienzen:
Wir nennen dies die „Builder’s Tax“ (Entwicklersteuer): eine strukturelle Ineffizienz, die aus entkoppelten operativen und analytischen Stacks resultiert. Für die Menschen in Technologieunternehmen, die die Plattformen, SaaS-Produkte und Entwicklertools bauen, auf denen alle anderen aufbauen, ist diese Steuer besonders schädlich. Jede neue KI-Funktion bringt eine weitere Datenbank, eine weitere Pipeline und ein weiteres Quartal Verzögerung mit sich.
Um dieses Muster zu durchbrechen, überdenken führende Technologieunternehmen ihre Architektur und gehen über die Einführung eines weiteren spezialisierten Tools hinaus. Wir sehen, wie sie Apps und KI direkt auf derselben, verwalteten Grundlage wie ihre Analysen ausführen.
Diese Grundlage ist Lakebase: eine vollständig verwaltete, serverlose Postgres-Engine, die nativ in die Databricks Platform integriert ist.
Dies schafft eine interoperable Anwendungsplattform: eine einzige, verwaltete Ebene, auf der Apps, KI und Analysen denselben operativen Speicher nutzen.
Amey Banarse präsentierte „From Transactions to Agents: PostgreSQL in Modern AI Applications“ auf der PostgresConf 2026 [Folien]. Amey zeigt einen Live-Walkthrough einer Healthtech-Claims-App, die vollständig auf Lakebase + dem AI DevKit basiert, und demonstriert, wie Lakehouse-Intelligenz, operative Einblicke und eine kontinuierliche Lernschleife auf einer einzigen Databricks-Grundlage laufen.
Organisationen steigen typischerweise über drei Hauptwege in diese Architektur ein:
Die folgenden Ergebnisse stammen von Technologieunternehmen, die zu einer Lakebase-Architektur gewechselt sind:

YipitData skalierte seine KI-Agenten-Pipeline zur Verarbeitung von 1 Million Datensätzen pro Stunde, erreichte eine Tagging-Genauigkeit von 92–95 % und eine 20-fache Abdeckung des Unternehmens. Durch die Verwendung von Lakebase als relationales System of Record innerhalb von Unity Catalog arbeiten ihre Agenten mit einem dauerhaften, verwalteten Zustand – keine fragilen externen Speicher, keine Synchronisierungsverzögerung.
Quantum Capital Group verwaltete über 1,5 Milliarden Datensätze aus sechs fragmentierten Datenquellen. Nach der Konsolidierung auf Lakebase eliminierten sie über 100 redundante Tabellen, reduzierten den Zeitaufwand für Data Engineering um 50 % und verdreifachten die Berichtsgeschwindigkeit – Teams arbeiten nun mit einem einzigen, vertrauenswürdigen Datensatz, anstatt mit Versions-Sprawl zu kämpfen.
Ensemble Health Partners konsolidierte über 15 fragmentierte SQL Server-Systeme. Mit Lakebase als Transaktionsschicht implementierten sie KI-gesteuerte Revenue-Cycle-Workflows, die die operative Effizienz um 20 % verbesserten und den Kunden halfen, jedes Jahr 3–5 % mehr Nettoumsatz zu erzielen.
Replit, dessen Plattform Millionen von Entwicklern beim Erstellen und Bereitstellen von Software unterstützt, nutzt Lakebase + das Databricks AI DevKit, um Kunden bei der Einführung von Produktions-Code-Generierungs-KI in 3 Wochen mit 10-facher Entwicklergeschwindigkeit zu unterstützen und die Lücke zwischen operativen und analytischen Systemen von Anfang an zu schließen.
IntentHQ, eine Plattform für Kundenintelligenz, zentralisierte seine Serving-Schicht auf Lakebase, um Echtzeit-Personalisierung in großem Maßstab zu ermöglichen – und gibt KI-Modellen einen operativen Speicher mit geringer Latenz, der mit seinen Lakehouse-Daten synchron bleibt, ohne benutzerdefinierte Pipelines.
Trotz unterschiedlicher Anwendungsfälle – von KI-Agenten und Personalisierungs-Engines bis hin zu Gesundheits-Workflows und Entwicklerplattformen – erzielen diese Organisationen ihre Erfolge nicht durch isolierte Optimierungen. Sie konvergieren auf ein grundlegend anderes Architekturmodell.
Im Kern eliminiert dieses Architekturmodell die traditionelle Trennung zwischen Transaktionssystemen, Analyseplattformen und KI-Pipelines und ersetzt sie durch eine gemeinsame, interoperable Datenbasis.
Dieses Muster umfasst durchgängig drei eng integrierte Ebenen:
Lakehouse-Intelligenzschicht
Eine verwaltete, skalierbare Grundlage, auf der Batch- und Streaming-Daten, Feature Engineering und KI/ML-Workloads ausgeführt werden. Diese Ebene bietet das System der Erkenntnis und ermöglicht die Verarbeitung großer Datenmengen, das Modelltraining und die Analyse auf vereinheitlichten Daten.
Operative Datenschicht
Eine Transaktionsschnittstelle mit geringer Latenz (Lakebase), die als System der Ausführung für Anwendungen und Agenten dient. Diese Ebene ermöglicht Echtzeit-Lese-/Schreibvorgänge, Zustandsverwaltung und Anwendungslogik direkt auf verwalteten Daten – ohne Replikations- oder Synchronisierungsaufwand.
Kontinuierliche Lernschleife
Ein geschlossenes Feedbacksystem, in dem Anwendungsinteraktionen, Agentenausgaben und Benutzersignale erfasst und in Modell-Pipelines integriert werden. Dies etabliert ein System der kontinuierlichen Verbesserung, das es KI-Funktionen ermöglicht, sich basierend auf realen Anwendungsfällen weiterzuentwickeln.
Wenn diese drei Ebenen eine gemeinsame Grundlage haben, entwickeln sich KI-Systeme von isolierten Workloads zu sich kontinuierlich verbessernden Produktionssystemen.
Die „Builder’s Tax“ ist nicht unvermeidlich. Sie ist eine Folge der Erstellung von KI auf einer Infrastruktur, die für eine andere Ära konzipiert wurde – als Datenbanken monolithisch waren, Apps zustandslos waren und Intelligenz ein separates Projekt darstellte.
Lakebase ändert die Gleichung! Apps laufen dort, wo die Daten liegen. Agenten haben den benötigten Kontext. Und die Entwicklungszeit, die Ihr Team für Pipelines aufgewendet hat, fließt zurück in die Auslieferung.
Sehen Sie sich Amey Banarses PostgresConf 2026-Sitzung „From Transactions to Agents: PostgreSQL in Modern AI Applications“ an [Folien] um eine vollständige AI-native App zu sehen, die auf Lakebase aufbaut.
Databricks Lakebase ist serverloses Postgres für Agenten und Apps. Erfahren Sie mehr unter databricks.com/product/lakebase.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.