von Bryan Smith
nOps, ein Databricks Built On-Partner, der über 4 Milliarden US-Dollar an jährlichen Cloud-Ausgaben verwaltet, migrierte seine Produktionsanwendung zu Databricks Lakebase. Das Ergebnis war eine schnellere, einfachere Architektur, die die Verbindung zwischen ihrer App und ihren Analysen eliminierte, und ein Leitfaden für ISVs, die dasselbe tun möchten.
Jeder ISV, der auf Databricks aufbaut, stößt irgendwann auf dieselbe architektonische Kreuzung: Ihre Analysen leben im Lakehouse, aber Ihre Anwendung benötigt eine relationale Datenbank für Lese- und Schreibvorgänge mit geringer Latenz. Also fügen Sie eine separate Postgres-Instanz hinzu (vielleicht RDS, vielleicht etwas selbstverwaltetes) und plötzlich warten Sie ETL-Pipelines, Cron-Jobs und Änderungs-Erkennungslogik, nur um zwei Systeme synchron zu halten.
nOps lebte diese Realität jahrelang. Und dann fanden sie einen besseren Weg.
Für diejenigen, die es nicht kennen: nOps ist eine automatisierte Cloud-Kostenoptimierungsplattform, die verbindliche Rabatte über AWS, GCP und Azure verwaltet. Ihr Ansatz ist eindeutig "immer aktiv". Sie überwachen, kaufen und tauschen Cloud-Verpflichtungen stündlich aus und nutzen maschinelles Lernen, um effektive Einsparungsraten gegen das Risiko der Bindung an Verpflichtungen abzuwägen. Das Modell ist leistungsbasiert: nOps berechnet nur einen Prozentsatz der zusätzlichen Einsparungen, die sie generieren.
Es ist ein datenintensiver Vorgang. Jede Stunde analysiert nOps Nutzungsmuster über Tausende von Kundenkonten hinweg, bewertet Verpflichtungsportfolios über drei große Cloud-Anbieter und Dutzende von Diensten und trifft automatisierte Kaufentscheidungen. Darüber hinaus bieten sie Kostenübersicht, Prognosen und Anomalieerkennung über eine zentralisierte FinOps-Plattform.
Das analytische Rückgrat all dessen war lange Zeit Databricks Lakehouse. Aber die Frontend-Anwendung, die Plattform, in die sich Kunden einloggen, um ihre Einsparungen zu sehen, Budgets zu verwalten und Kostendaten zu erkunden, brauchte etwas mehr.
Die frühere Architektur von nOps war ein bekanntes Muster für ISVs auf Databricks. Erweiterte Analysen und Metrikberechnungen liefen im Lakehouse. Kundenseitige Daten (Kontokonfigurationen, Benutzereinstellungen, sich schnell ändernde kundenspezifische Zustände) befanden sich in einer separaten relationalen Datenbank, die von Drittanbietern und Eigenentwicklungen betrieben wurde.
Die Nahtstellen zwischen diesen beiden Systemen erzeugten echte Reibung. Geplante Jobs und Cron-basierte Änderungs-Erkennung waren erforderlich, um die Frontend-Datenbank und das Lakehouse synchron zu halten. Daten, die in einem System "live" waren, konnten Minuten oder länger brauchen, um im anderen aufzutauchen. Und der operative Aufwand für die Verwaltung eines separaten Datenbank-Stacks mit eigenen Skalierungs-, Backup- und Sicherheitsbedenken zog Entwicklungszeit von dem ab, was nOps eigentlich am besten kann: die Automatisierung von Verpflichtungen.
Als nOps Anfang 2026 von AWS-only auf Multi-Cloud-Abdeckung über GCP und Azure expandierte, belasteten die wachsenden Workloads diese Architektur. Das Team beschloss, die Plattform neu aufzubauen, diesmal mit Fokus auf ihre Spezialität und der Wahl einer Infrastruktur, die einfach funktioniert.
nOps wählte Databricks Lakebase, eine vollständig verwaltete PostgreSQL-Datenbank, die direkt in das Lakehouse integriert ist, als OLTP-Rückgrat für ihre neue Plattform.
Jordan Stein, Director of Product bei nOps, nannte drei Faktoren, die Lakebase zur richtigen Wahl machten:
So sieht die neue Architektur von nOps aus:
Lakebase dient als zentrale Postgres-Datenbank und einzige Quelle der Wahrheit sowohl für die Frontend-Anwendung als auch für ihre AI-Infrastruktur.
Databricks Lakehouse konsumiert kontinuierlich Daten aus Lakebase für Analyse und Metrikberechnung.
Die nOps-Plattform erkennt und stellt Databricks Metric Views automatisch bereit, sodass standardisierte Metriken, die im Lakehouse berechnet werden, konsistent im Frontend angezeigt werden.
Daten fließen in eine Richtung, von Lakebase in das Lakehouse für Analysen, ohne dass ein direktes Zurückschreiben erforderlich ist. Dies hält die Architektur sauber und die Quelle der Wahrheit eindeutig.
Der Rest des Stacks folgt dem gleichen Ansatz: Vercel für Hosting und Observability, WorkOS für Authentifizierung und Databricks für alle Daten.
Jordan Stein hat kürzlich die gesamte Migrationsgeschichte von nOps Lakebase in einer Partner-Spotlight-Präsentation vorgestellt. Sehen Sie sich das Video an, um zu erfahren, wie der Übergang verlief, was sie an der Leistung überraschte und wie die Lakehouse-Integration ihre Daten-Engineering-Workflows veränderte:
Die Geschichte von nOps ist nicht einzigartig. Fast jeder ISV, der auf Databricks aufbaut, steht vor derselben Spannung zwischen OLTP und Analysen. Bemerkenswert ist, wie sauber Lakebase dies löst.
Eliminieren Sie die Synchronisations-Steuer. Der teuerste Code in jedem ISV-Stack ist oft der Code, der Daten zwischen Systemen verschiebt. Die native Integration von Lakebase mit Unity Catalog und die Ein-Klick-Delta Lake-Synchronisierung ersetzen benutzerdefinierte ETL-Pipelines durch verwaltete Infrastruktur. Das ist Ingenieurszeit, die Sie zurückgewinnen.
Ein Governance-Modell. Wenn Ihre OLTP-Datenbank als Unity Catalog-Asset registriert ist, erhalten Sie eine einheitliche Governance, Lineage und Zugriffssteuerung über operative und analytische Daten hinweg. Kein Verwalten von Sicherheitsrichtlinien mehr an zwei Stellen.
Postgres-Kompatibilität bedeutet keine Neuschreibung. Lakebase ist vollständig verwaltetes PostgreSQL. Ihre vorhandenen Bibliotheken, ORMs und SQL-Tools funktionieren sofort. Erweiterungen wie pgvector und PostGIS werden unterstützt. Sie migrieren, indem Sie Ihre App auf eine neue Verbindungszeichenfolge verweisen, nicht indem Sie Abfragen neu schreiben.
Skalierungsökonomie, die Sinn macht. Nutzungsbasierte Preisgestaltung mit Skalierung auf Null bedeutet, dass Sie nicht für ungenutzte Kapazität bezahlen. Für ISVs mit variablen Workloads (und welcher ISV hat keine variablen Workloads?) wirkt sich dies direkt auf die Stückkosten aus.
Schneller liefern. Wenn Ihre Anwendungsdatenbank und Ihr Data Warehouse dieselbe Plattform sind, entfällt eine ganze Kategorie von Integrationsarbeiten. Ihr Team liefert Funktionen, anstatt die Infrastruktur zu warten.
nOps ist ein gutes Beispiel dafür, wie ein innovativer Built On-Partner aussieht. Anstatt darauf zu warten, dass Lakebase über mehrere Release-Zyklen hinweg reift, erkannten sie frühzeitig die architektonische Eignung, verpflichteten sich zu einer Produktionsmigration und sehen bereits Ergebnisse: schnellere Datenpipelines, geringere Betriebskosten und ein besseres Erlebnis für ihre Kunden.
Diese Bereitschaft, frühzeitig zu handeln, ist auch strategisch klug. Durch den Aufbau auf Lakebase hat nOps jetzt eine engere Integration mit der Databricks-Plattform als Wettbewerber, die immer noch separate Datenbank-Stacks zusammenflicken. Ihre Plattform ist einfacher zu bedienen und schneller zu erweitern.
Lakebase erkunden. Wenn Sie ein ISV sind, der auf Databricks aufbaut oder dies in Betracht zieht, erfahren Sie mehr über Lakebase und wie es Ihre Architektur vereinfachen kann.
nOps erkunden. Wenn Ihr Unternehmen Cloud-Kosten über AWS, GCP oder Azure ohne das Risiko einer Bindung reduzieren möchte, besuchen Sie nOps, um zu sehen, wie ihre automatisierte Optimierungsplattform, jetzt powered by Databricks Lakebase, helfen kann.
(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.