Direkt zum Hauptinhalt
Technologie

Wie führende Technologieunternehmen die Builder-Steuer mit Lakebase abschaffen

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

  • Datenbewegungs-Layer reduzieren: Führende Unternehmen nutzen Databricks Lakebase und eliminieren ETL und Reverse ETL, indem sie operative und analytische Daten auf einer einzigen, verwalteten Plattform vereinheitlichen.
  • Echtzeit-Intelligenz ermöglichen: Anwendungen und KI-Systeme arbeiten direkt mit frischen Daten mit geringer Latenz ohne Synchronisierungsverzögerung.
  • KI-Systeme produktiv einsetzen: Eine einheitliche Architektur reduziert den Betriebsaufwand und ermöglicht kontinuierliche Lernschleifen im großen Maßstab.

Die versteckten Kosten, die Ihre KI-App-Roadmap zerstören

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:

  • Veraltete Daten: KI-Systeme arbeiten mit verzögerten Snapshots statt mit Echtzeit-Zuständen
  • Architektonische Fragmentierung: Governance, Lineage und Zugriffskontrolle werden über Systeme hinweg dupliziert
  • Operativer Mehraufwand: Der Engineering-Aufwand verlagert sich von der Produktentwicklung hin zur Pipeline-Orchestrierung und Fehlerverwaltung

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.

Architektonischer Wandel: Apps und Daten zusammenlegen

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.

  • Apps lesen und schreiben direkt auf Lakehouse-verwaltete Daten
  • Die Governance wird zentral über Unity Catalog für alle Workloads gesteuert
  • Zuverlässige operative Daten mit automatisierten Snapshots und integrierter Fehlerwiederherstellung
Dies schafft eine interoperable Anwendungsplattform: eine einzige, verwaltete Ebene, auf der Apps, KI und Analysen denselben operativen Speicher nutzen.

Reales Szenario

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:

  • Eliminierung von Reverse-ETL-Pipelines: Analytische Datensätze (Gold-Layer-Tabellen) werden durch native Integration direkt in Lakebase synchronisiert. Dies beseitigt die Abhängigkeit von externen Tools und reduziert die Fragilität von Pipelines.
  • KI-native Apps und interne Tools: Führen Sie Databricks Apps + Lakebase als einzelnen, serverlosen Stack mit Model Serving, Feature Store und Analysen aus. Keine zusätzliche Infrastruktur bereitzustellen.
  • Agenten-Gedächtnis und Zustand: Lakebase mit pgvector für semantische Suche wird zur operativen Gedächtnisschicht für Agenten, die mit Agent Bricks erstellt wurden, zusammen mit den Daten, über die sie nachdenken.

Was Technologieunternehmen tatsächlich sehen

Die folgenden Ergebnisse stammen von Technologieunternehmen, die zu einer Lakebase-Architektur gewechselt sind:

Tech industry Lakebase customer logos

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.

Das Architekturmuster hinter den Ergebnissen

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:

  1. 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.

  2. 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.

  3. 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“ eliminieren

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

Erhalten Sie die neuesten Beiträge in Ihrem Posteingang

Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.