Databricks stellt Verbesserungen am Compute-Cache von Lakebase Postgres vor
Laut Databricks senken größere gemeinsame Postgres-Puffer und neue Huge-Page-Speicherunterstützung auf großen Lakebase-Rechenknoten die Latenz und CPU-Auslastung, wobei Produktionstests einen bis zu zweifachen Durchsatzgewinn zeigen.
Kurze Antwort
Was hat Databricks zur Verbesserung des Compute-Caches von Lakebase Postgres angekündigt?
Databricks erklärt, die gemeinsamen Postgres-Puffer auf großen Lakebase-Rechenknoten fester Größe (ab CU 80) auf 75 Prozent des DRAM erhöht und dedizierte Huge-Page-Speicherunterstützung hinzugefügt zu haben. Damit ersetzt das Unternehmen eine bisherige Lösung mit lokalem Datei-Cache, die die gemeinsamen Puffer auf knapp 1 GB begrenzte. Laut Unternehmensangaben ergeben sich in der Produktion Durchsatzgewinne von bis zu 2x, weniger Storage-Lesezugriffe sowie eine geringere CPU-Auslastung und Latenz.
Das Wichtigste
- Databricks zufolge wurden die gemeinsamen Postgres-Puffer auf großen Lakebase-Rechenknoten fester Größe (ab CU 80) von einer Obergrenze von rund 1 GB auf 75 Prozent des verfügbaren DRAM angehoben, während der lokale Datei-Cache auf diesen Knoten deaktiviert wurde.
- Das Unternehmen erklärt, in seiner gesamten virtuellen Maschineninfrastruktur eine dedizierte Unterstützung für 2-MB-Huge-Pages eingeführt zu haben, um den durch größere gemeinsam genutzte Puffer verursachten Mehraufwand bei der Speicheradressübersetzung zu verringern.
- Databricks berichtet von Benchmark-Tests, wonach Huge Pages die Tail-Latenz beim Lesen um bis zu rund 40 Prozent senken und die CPU-Auslastung um bis zu rund 30 Prozent reduzieren.
- In von Databricks angeführten Praxisbeispielen stieg der Durchsatz bei einem Endpunkt für den Zugriff auf Blöcke um etwa das Doppelte, während die Lesezugriffe auf der Storage-Ebene um rund das Fünffache zurückgingen; bei einem anderen sank die CPU-Auslastung von 20 auf 4 Kerne.
- Databricks zufolge begann die Einführung einige Wochen vor dem Beitrag vom 10. September 2026 Region für Region, und ein geplanter zweiter Beitrag soll sich mit der Arbeit an autoskalierenden gemeinsamen Puffern befassen.
Was Databricks angekündigt hat
Databricks hat am 10. September 2026 einen Blogbeitrag veröffentlicht, in dem beschrieben wird, wie der Lakebase-Postgres-Dienst des Unternehmens künftig Daten auf Compute-Knoten zwischenspeichert. Der als erster Teil einer Serie angekündigte Beitrag stammt von David Wein, Sunil Kamath und Haoyu Huang. Ziel sei es, den auf Lakebase-Compute verfügbaren DRAM effizienter zu nutzen, indem mehr Daten in Postgres' schnellster Speicherschicht gehalten werden.
Hintergrund zum Caching
Lakebase Postgres setzt laut Databricks auf ein disaggregiertes Speichermodell, bei dem sowohl im verteilten Storage als auch auf dem Compute-Knoten selbst zwischengespeichert wird. In einer Standard-Postgres-Installation cacht die Datenbank Daten in einem Speicherbereich namens Shared Buffers, während das Betriebssystem dieselben Seiten zusätzlich in seinem eigenen Page Cache vorhält – ein Aufbau, der laut Databricks zu doppelter Pufferung führt, sodass 1 GB gecachter Daten am Ende 2 GB RAM belegen kann. Databricks weist zudem darauf hin, dass die Größe der Postgres-Shared-Buffers normalerweise eine statische Einstellung ist, die sich nur mit einem Datenbank-Neustart ändern lässt – eine Herausforderung für ein serverloses, automatisch skalierendes System.
Um dies zu umgehen, hat Databricks nach eigenen Angaben einen lokalen Datei-Cache (Local File Cache, LFC) entwickelt, der seit dem Start auf sämtlichen Lakebase-Compute-Instanzen läuft. Der LFC liegt auf dem lokalen NVMe-Speicher des Compute-Knotens als zweite Ebene hinter den Shared Buffers, die Databricks bislang konservativ eingestellt hatte – gedeckelt auf etwa 1 GB, unabhängig vom insgesamt verfügbaren Arbeitsspeicher.
Größere Shared Buffers und Huge Pages
Databricks hat diese Obergrenze von rund 1 GB nun für große, fest dimensionierte Compute-Knoten aufgehoben. Bei Computes mit einer CU von 80 oder mehr deaktiviert das Unternehmen den LFC und setzt die Postgres-Shared-Buffers auf 75 % des verfügbaren DRAM, sodass häufig genutzte Seiten in der schnellsten Speicherschicht bleiben, statt in den langsameren lokalen Cache abzuwandern. Kunden können die Konfiguration laut Databricks prüfen, indem sie in einer Postgres-Verbindung „show shared_buffers" ausführen; für einen 80-CU-Endpoint sollte dabei der Wert 20971520 zurückgegeben werden.
Da größere Shared Buffers im Prozess-pro-Verbindung-Design von Postgres den Aufwand für die Speicheradressierung erhöhen, hat Databricks nach eigenen Angaben zudem dedizierte Unterstützung für 2-MB-Huge-Pages in seiner gesamten virtuellen Infrastruktur eingeführt – mit expliziten HugeTLB-Pages statt der Best-Effort-Variante Transparent Huge Pages. Dafür sei durchgängige Unterstützung vom Host über den Hypervisor bis zum Gast-Kernel nötig gewesen. Kunden können die Einstellung mit „show huge_pages" überprüfen, was bei einem 80-CU-Endpoint laut Databricks „on" zurückgeben sollte.
Berichtete Ergebnisse
Laut Databricks zeigten Benchmark-Tests, dass Huge Pages die Tail-Latenz beim Lesen um bis zu rund 40 % senkten und die CPU-Auslastung um bis zu etwa 30 % reduzierten. Der Rollout habe einige Wochen vor Veröffentlichung des Beitrags regionsweise begonnen; das Unternehmen führt drei nach Compute-Neustarts gemessene Praxisbeispiele an. Bei einem großen Endpoint habe sich die Zahl der pro Sekunde abgerufenen Postgres-Blöcke verdoppelt, während die Lesezugriffe auf die Storage-Schicht von rund 8.000 pro Sekunde auf etwa 1.500 gesunken seien; der Kunde habe zudem niedrigere p50- und p99-Latenzen als am Vortag, in der Vorwoche und im Vormonat gemeldet. Bei einem zweiten Endpoint sei der Durchsatz um rund 43 % gestiegen, und die Trefferquote des Compute-Caches habe nahezu 100 % erreicht. Bei einem dritten sei die CPU-Nutzung nach der Umstellung von 20 auf 4 Kerne gesunken, bei gleichzeitig verdoppeltem Durchsatz.
Die aktuellen Änderungen gelten laut Databricks zunächst nur für fest dimensionierte Computes, da sich Shared Buffers noch nicht dynamisch skalieren lassen. Ein für die Serie geplanter zweiter Beitrag soll sich mit der Arbeit an automatisch skalierenden Shared Buffers befassen.
Quelle: Databricks Blog, „Improving Lakebase Postgres compute cache", veröffentlicht am 10. September 2026.
Häufige Fragen
- Was ist die von Databricks angekündigte Änderung am Compute-Cache von Lakebase Postgres?
- Databricks erklärt, die gemeinsamen Postgres-Puffer auf großen Rechenknoten fester Größe (ab CU 80) auf 75 Prozent des verfügbaren DRAM erhöht zu haben. Damit wird eine bisherige Konfiguration ersetzt, die die gemeinsamen Puffer auf knapp 1 GB begrenzte und auf einen zusätzlichen lokalen Datei-Cache angewiesen war.
- Welche Leistungsverbesserungen berichtet Databricks?
- Databricks nennt Produktionsbeispiele mit Durchsatzsteigerungen von etwa dem 1,3- bis 2-Fachen, einem an einem Endpunkt um bis zu das Fünffache gesunkenen Lesezugriff auf der Storage-Ebene sowie einer an einem anderen Endpunkt von 20 auf 4 Kerne gesunkenen CPU-Auslastung.
- Wie ist Databricks dem Mehraufwand durch größere gemeinsam genutzte Puffer begegnet?
- Das Unternehmen gibt an, in seiner gesamten VM-Infrastruktur dedizierte Unterstützung für 2-MB-Huge-Pages hinzugefügt zu haben, was in den eigenen Benchmark-Tests die Tail-Latenz beim Lesen um bis zu rund 40 Prozent und die CPU-Auslastung um bis zu rund 30 Prozent senkte.
- Gilt diese Änderung für alle Lakebase-Postgres-Computes?
- Databricks zufolge ist die Konfiguration mit größeren gemeinsamen Puffern derzeit nur für Rechenknoten fester Größe mit einer CU von 80 oder mehr verfügbar, während ein geplanter zweiter Beitrag sich mit autoskalierenden Rechenknoten befassen soll.