Databricks verbessert den Lakebase-Postgres-Compute-Cache, doch Autoscaling ist der eigentliche Test
Databricks verbessert die Leistung des Lakebase-Postgres-Compute-Caches mit einer neuen Konfiguration, die in Produktionsmessungen bis zu den doppelten Durchsatz erreichte. Die Änderung ist bereits auf Databricks-Computes mit fester Größe und mindestens 80 Compute Units aktiv. Das schwierigere Problem bleibt jedoch ungelöst: dieselbe Speicherstrategie auf Computes zu übertragen, die während des laufenden Postgres-Betriebs hoch- und herunterskalieren.
Das Update verändert, wo häufig angeforderte Datenbankseiten ihre Zeit verbringen. Große Computes mit fester Größe weisen nun bis zu 75 % des verfügbaren Speichers den Postgres Shared Buffers zu. Diese Puffer sind der schnellste In-Memory-Cache der Datenbank-Engine. Databricks unterlegt diesen Speicher zudem mit 2-MB-Huge-Pages, um den Aufwand für die Adressübersetzung im Betriebssystem zu senken.
Diese Kombination zielt auf einen zentralen Zielkonflikt entkoppelter Datenbanken. Die Trennung von dauerhaftem Speicher und Compute ermöglicht schnelle Neustarts, unabhängige Skalierung und kostengünstigen Objektspeicher. Sie vergrößert jedoch auch die Distanz zwischen einer laufenden Abfrage und den benötigten Daten. Amazon Aurora, AlloyDB und andere Cloud-Datenbanken stehen vor Varianten dieses Problems, doch Databricks wendet seine Lösung auf die Neon-Architektur unterhalb von Lakebase an.
Die Verbesserung des Lakebase-Postgres-Compute-Caches beginnt mit festen Computes
Databricks hat den heißesten Teil des Lakebase-Caches vom lokalen Datenträger in den Postgres-Speicher verlagert, jedoch nur auf ausreichend großen Maschinen mit fester Größe.
Die Änderung wurde am 9. September 2026 veröffentlicht. Laut dem Compute-Cache-Update des Unternehmens ist sie auf Lakebase-Computes mit fester Größe und mindestens 80 Compute Units aktiv. Der entsprechende Neon-Rollout umfasst feste Computes mit mindestens 18 Compute Units.
Lakebase verwendet entkoppelten Speicher, was bedeutet, dass Postgres-Compute und dauerhafter Datenspeicher als separate Ebenen arbeiten. Ein Compute-Knoten führt die Datenbank-Engine aus, besitzt jedoch nicht die maßgebliche Kopie der Daten. Dieses Design erlaubt es Betreibern, Compute zu ersetzen, neu zu starten oder zu skalieren, ohne eine gesamte Datenbank verschieben zu müssen.
Lesevorgänge durchlaufen eine Hierarchie. Postgres prüft zunächst die Shared Buffers im DRAM. Fehlt die Seite dort, prüft die frühere Konfiguration einen lokalen Dateicache auf dem NVMe-Laufwerk des Compute-Knotens. Ein weiterer Fehlzugriff sendet die Anfrage an die verteilte Speicherebene, in der Pageserver Datenbankseiten rekonstruieren und zurückgeben.
Dieser lokale Dateicache löste ein wichtiges frühes Problem. Standard-Postgres-Installationen profitieren normalerweise sowohl von Shared Buffers als auch vom Page Cache des Betriebssystems. Lakebase leitet entfernte Seitenlesevorgänge nicht über ein herkömmliches lokales Dateisystem, sodass es sich nicht auf die normale zweite Ebene verlassen kann.
Databricks und Neon entwickelten den lokalen Dateicache daher als elastischen Ersatz. Er konnte Kapazität über die statische Postgres-Pufferzuweisung hinaus belegen und sich gemeinsam mit serverlosem Compute anpassen. Dieses Arrangement unterstützte Autoscaling, ohne dass Postgres seine Shared Buffers während des Betriebs vergrößern musste.
Die vorherige Konfiguration begrenzte die Shared Buffers jedoch auf etwa 1 GB. Der Großteil der verbleibenden Compute-Cache-Kapazität, die bis zu 75 % des DRAM erreichen konnte, entfiel auf den lokalen Dateicache. Auf großen Maschinen leitete dieses Gleichgewicht viele ansonsten cachefähige Lesevorgänge über NVMe statt über den Speicher.
Die neue Konfiguration für feste Computes entfernt den lokalen Dateicache aus diesem Pfad. Sie weist 75 % des DRAM den Shared Buffers zu und hält damit einen wesentlich größeren Working Set innerhalb von Postgres. Ein Databricks-Endpunkt mit 80 Units sollte laut Ankündigung 120 GB melden, wenn ein Administrator show shared_buffers ausführt.
Der Zugriff auf DRAM vermeidet die Datenträger-Ein- und -Ausgabe, die der lokale Cache erfordert. Zudem erhält Postgres direkte Kenntnis über gecachte Seiten und deren Nutzung. Ein Betriebssystem-Cache oder eine separate Datenträgerebene verfügt bei der Entscheidung, welche Seite verworfen wird, über weniger Informationen zum Datenbankzustand.
Das ist die unmittelbare Bedeutung der Verbesserung des Lakebase-Postgres-Compute-Caches. Es handelt sich nicht um einen neuen Index, Query Planner oder ein neues Speicherformat. Databricks hat die Speicherzuweisung und die Virtual-Memory-Mechanismen rund um die bestehende Postgres-Ausführungs-Engine geändert.
Der Umfang ist wichtig. Bereitstellungen mit fester Größe können Shared Buffers beim Start zuweisen, weil ihre Speicherobergrenze bekannt bleibt. Autoscaling-Endpunkte können dieselbe Annahme nicht treffen. Ihr verfügbarer Speicher ändert sich mit der Arbeitslast, während die Standard-Postgres-Einstellung nach dem Start statisch bleibt.
Deshalb ist die erste Veröffentlichung bedeutsam, ohne vollständig zu sein. Databricks hat gezeigt, dass eine direktere Speichernutzung große Lakebase-Endpunkte verbessern kann. Das Unternehmen hat dieses Design jedoch noch nicht für das serverlose Betriebsmodell bereitgestellt, das entkoppeltes Postgres attraktiv macht.
Warum die Leistung des Lakebase-Caches zur Priorität wurde
Die Speichertrennung schafft operative Flexibilität, doch jeder Cache-Miss legt die durch diese Flexibilität verborgenen Latenz- und CPU-Kosten offen.
Traditionelles Postgres kombiniert üblicherweise Query Engine, Write-Ahead Log und Datenbankdateien auf einer Maschine oder eng verbundenem Speicher. Das Betriebssystem kann kürzlich abgerufene Dateiseiten in seinem Page Cache behalten. Postgres hält außerdem ausgewählte Seiten in Shared Buffers.
Dieses Arrangement kann Daten im Speicher duplizieren. Databricks nennt das Beispiel einer Maschine mit 4 GB RAM und 1 GB für Shared Buffers. Das Lesen von 1 GB über das Dateisystem kann eine weitere Kopie im Betriebssystem-Cache hinterlassen und 2 GB verbrauchen, um 1 GB Datenbankseiten zu cachen.
Lakebase verändert diesen Pfad. Seine Speicherarchitektur unterteilt das System in zustandsloses Postgres-Compute und einen dauerhaften Speicherdienst. Safekeepers replizieren Write-Ahead-Log-Einträge, während Pageserver Seitenversionen rekonstruieren und sie im Objektspeicher persistieren.
Die Architektur ermöglicht es, Compute unabhängig von gespeicherten Daten zu skalieren. Sie unterstützt Funktionen wie Scale-to-Zero, schnelles Branching, Read Replicas und Failover, ohne eine gesamte Datenbank zu kopieren. Diese Vorteile hängen davon ab, den dauerhaften Zustand außerhalb des Compute-Knotens zu halten.
Zustandsloses Compute benötigt bei der Verarbeitung von Abfragen dennoch lokal verfügbaren Zustand. Anwendungen greifen wiederholt auf Indizes, Tabellenseiten, Katalogeinträge und andere Strukturen zu. Bleiben diese Seiten im DRAM, werden Lesevorgänge über den Teil der Hierarchie mit der geringsten Latenz abgeschlossen.
Ein Fehlzugriff in den Shared Buffers nimmt einen längeren Weg. Der lokale NVMe-Cache ist schneller als entfernter Speicher, erfordert jedoch weiterhin Datenträgerzugriff und zusätzliche Softwareverarbeitung. Ein Fehlzugriff dort erreicht den Pageserver und kann Netzwerkverkehr sowie Arbeit zur Seitenrekonstruktion verursachen.
Der daraus resultierende Druck trifft Teams, die große Lakebase-Instanzen für latenzsensitive Anwendungen einsetzen. Diese Kunden stellen umfangreichen Speicher bereit, doch die frühere Obergrenze von 1 GB für Shared Buffers verhinderte, dass Postgres den Großteil dieses Speichers über seinen schnellsten Cache-Pfad nutzte.
Mit wachsendem Working Set wird dieses Missverhältnis deutlicher. Ein Working Set ist die Sammlung von Seiten, auf die eine Anwendung in einem bestimmten Zeitraum häufig zugreift. Übersteigt es den kleinen Speichercache, gelangen Anfragen in langsamere Ebenen, selbst wenn die Maschine über reichlich DRAM verfügt.
Databricks benötigte eine bessere Antwort, weil Lakebase inzwischen operative Workloads bedient, nicht nur analytische Jobs. Nutzerorientierte Anwendungen achten auf Tail Latency, die langsamere Anfragen am äußersten Ende einer Latenzverteilung widerspiegelt. Durchschnittswerte können akzeptabel bleiben, während p99-Anfragen weiterhin sichtbare Verzögerungen verursachen.
Auch KI-Anwendungen üben ungleichmäßigen Druck auf operative Datenbanken aus. Ein Agent kann Schübe von Abrufen, Schreibvorgängen, Checkpoints und parallelen Tool-Aufrufen auslösen. Vorhersagbares Cache-Verhalten gewinnt an Bedeutung, wenn Traffic in Clustern statt als stetiger Anfragefluss eintrifft.
Das bedeutet nicht, dass jede Arbeitslast gleichermaßen profitiert. Ein Datensatz, der bereits in die frühere Shared-Buffer-Zuweisung passt, bietet weniger Verbesserungspotenzial. Eine scanintensive Arbeitslast mit geringer Seitenwiederverwendung kann unabhängig von der Puffergröße weiterhin niedrigere Cache-Ebenen erreichen.
Die stärksten Kandidaten sind große Endpunkte mit wiederverwendbaren Working Sets, die das frühere Limit von 1 GB überschritten. Ihr vorhandener Speicher kann jetzt mehr häufig benötigte Seiten direkt innerhalb von Postgres halten. Deshalb präsentierte Databricks Produktionsbeispiele, statt eine universelle Verdopplung zu versprechen.
Die Lakebase-Cache-Leistung hängt daher ebenso stark von der Form der Arbeitslast wie von der Maschinengröße ab. Die neue Konfiguration beseitigt einen architektonischen Engpass. Sie hebt die grundlegenden Regeln für Cache-Lokalität, Abfragedesign, Indizierung oder Speicherkonkurrenz nicht auf.
Huge Pages machen den größeren Buffer Pool praktikabel
Die Zuweisung von mehr Speicher an Postgres würde eigene Overheads erzeugen, wenn Lakebase nicht zugleich die Kosten für das Mapping dieses Speichers über Datenbankprozesse hinweg senken würde.
Postgres verwendet eine prozessbasierte Architektur. Jede aktive Verbindung erhält in der Regel einen Backend-Prozess, und jedes Backend mappt die Shared-Buffer-Region in seinen virtuellen Adressraum. Das Betriebssystem verwaltet Seitentabelleneinträge, die diese virtuellen Adressen in physische Speicherorte übersetzen.
Standard-Linux-Speicherseiten sind üblicherweise 4 KB groß. Bei dieser Seitengröße erfordert 1 GB Shared Buffers 262.144 Seitentabelleneinträge für jeden Prozess, der die Region mappt. Databricks berechnet, dass 32 GB Shared Buffers über 512 Backends hinweg etwa 4,3 Milliarden Einträge erfordern können.
Das Unternehmen schätzt, dass diese Einträge rund 32 GB an Seitentabellen verbrauchen würden, nur um einen 32-GB-Cache zu mappen. Dies ist eine extreme Veranschaulichung dafür, wie eine größere Pufferzuweisung den Overhead an anderer Stelle erhöhen kann. Mehr Cache-Kapazität ist nicht automatisch nützlich, wenn die Speicherverwaltung übermäßig viel RAM und CPU-Zeit verbraucht.
Der Prozessor unterhält außerdem einen Translation Lookaside Buffer, kurz TLB. Dieser Hardware-Cache speichert kürzlich verwendete Übersetzungen virtueller in physische Adressen. Eine Datenseite kann im Postgres-Speicher vorhanden sein, während die CPU nach einem TLB-Miss dennoch einen Nachteil beim Auffinden trägt.
Huge Pages verringern diesen Druck, indem sie Speicher in größeren Einheiten mappen. Lakebase verwendet für die neue Fixed-Compute-Konfiguration explizite 2-MB-HugeTLB-Pages. Jede Huge Page deckt 512-mal so viel Speicher ab wie eine Standardseite mit 4 KB und reduziert damit die Anzahl erforderlicher Mapping-Einträge um denselben Faktor.
PostgreSQL bietet bereits Betriebssystemsteuerungen für Huge Pages. Seine Ressourcendokumentation erläutert, dass explizite Huge Pages den Overhead großer zusammenhängender Shared-Memory-Regionen reduzieren können. Der Vorteil ist besonders relevant, wenn shared_buffers sehr groß wird.
Virtualisierung erschwert die Umsetzung. Lakebase führt Postgres innerhalb leichtgewichtiger Gast-VMs auf Bare-Metal-Hosts aus. Die Adressübersetzung durchläuft daher sowohl die Gast- als auch die Host-Ebene. Huge Pages müssen auf Host, Hypervisor und Gast durchgängig unterstützt werden, um ihren vorgesehenen Nutzen zu bewahren.
Databricks erklärt, dass es im gesamten Stack dedizierte Huge-Page-Unterstützung ergänzt hat. Große virtuelle Maschinen mit fester Größe starten mit einer vorab festgelegten Menge an Huge Pages. Nach der Initialisierung von Postgres gibt das Compute-System Kapazität frei, die die Datenbank nicht benötigt.
Das Unternehmen entschied sich für explizite HugeTLB-Pages statt für transparente Huge Pages. Transparente Huge Pages erlauben dem Betriebssystem, Speicher automatisch hochzustufen, doch dieses Verhalten erfolgt nach bestem Bemühen. Die explizite Reservierung verschafft der Datenbankumgebung eine präzisere Kontrolle über Seitenverfügbarkeit und Layout.
In Benchmarktests von Databricks reduzierten Huge Pages die Lese-Latenz im Tail-Bereich um bis zu etwa 40 %. Die CPU-Auslastung sank um bis zu etwa 30 %. Dabei handelt es sich um Unternehmensmessungen, nicht um unabhängige Garantien für jeden Lakebase-Workload.
Diese Unterscheidung ist wichtig, weil Huge Pages nicht die gesamte berichtete Verbesserung erklären. Zwei Änderungen wurden gleichzeitig eingeführt: Mehr Daten blieben in Shared Buffers, und der Zugriff auf diesen größeren Bereich erforderte weniger Seitenübersetzungen. Workloads können von beiden Mechanismen in unterschiedlichem Ausmaß profitieren.
Administratoren können die bereitgestellte Einstellung über Postgres überprüfen. Die Ausführung von show huge_pages sollte für einen berechtigten Lakebase-Endpunkt mit 80 Einheiten on zurückgeben. Zusammen mit dem Wert von shared_buffers bietet dies eine direkte Möglichkeit zu bestätigen, ob die neue Konfiguration eine Compute-Instanz erreicht hat.
Dieser Mechanismus erklärt auch, warum ein bloßes Erhöhen von shared_buffers für gewöhnliche Postgres-Bereitstellungen keine vollständige Lösung ist. Für die Datenbank reservierter Speicher muss mit Verbindungen, Abfrageoperationen, Wartungsjobs und den Anforderungen des Betriebssystems koexistieren. Eine große Zuweisung kann neue Einschränkungen schaffen, wenn das umgebende System nicht dafür ausgelegt ist.
Databricks kontrolliert die virtuellen Maschinen, Compute-Images, den Cache-Pfad und das Speicherprotokoll. Diese Ende-zu-Ende-Kontrolle ermöglicht es dem Unternehmen, die Reservierung von Huge Pages mit dem Start von Postgres zu koordinieren. Ein selbstverwaltetes Team müsste diese Ebenen unabhängig voneinander abstimmen und das Ergebnis unter dem eigenen Workload validieren.
Wie Lakebase-Caching funktioniert, ist daher komplexer als „mehr RAM verwenden“. Die Verbesserung hängt davon ab, heiße Daten im richtigen Speicherbereich zu platzieren, diesen Bereich effizient abzubilden und genügend Speicher für alles außerhalb des Buffer Pools zu bewahren.
Produktionsergebnisse zeigen Verbesserungen, keinen universellen Referenzwert
Databricks berichtet von erheblichen Verbesserungen bei drei Produktionsendpunkten, doch die veröffentlichten Beispiele belegen keinen plattformweiten Leistungsdurchschnitt.
Das erste Beispiel erhielt die neue Konfiguration am 11. August gegen 06:10 UTC. Die Anzahl der pro Sekunde abgerufenen Postgres-Blöcke verdoppelte sich, was Databricks als Durchsatzindikator nutzte. Die Storage-GetPage-Anfragen sanken von etwa 8.000 pro Sekunde auf etwa 1.500.
Der Kunde berichtete außerdem von niedrigeren Median- und p99-Latenzen als am vorherigen Tag, in der vorherigen Woche und im vorherigen Monat. Die Veröffentlichung nennt weder die zugrunde liegenden Latenzwerte noch die Workload-Definition, die Abfragemischung oder eine kontrollierte Vergleichsumgebung. Leser sollten die Beobachtung als Produktionsergebnis und nicht als standardisierten Benchmark verstehen.
Ein zweiter Endpunkt wurde am 14. August gegen 01:30 UTC umgestellt. Sein berichteter Durchsatz stieg um etwa 43 %, während seine Compute-Cache-Trefferrate nahezu 100 % erreichte. Nach dem Rollout wurden Anfragen fast vollständig aus Shared Buffers bedient.
Der dritte Endpunkt wurde am 15. August umgestellt. Laut Databricks sank der CPU-Verbrauch von 20 Kernen auf vier, die Cache-Trefferrate näherte sich 100 %, und der gemessene Durchsatz verdoppelte sich. Die fünffache Verringerung der CPU-Nutzung sticht hervor, doch der öffentliche Beitrag spezifiziert nicht, ob alle externen Workload-Bedingungen konstant blieben.
Zusammen stützen die Beispiele einen plausiblen Mechanismus. Mehr Anfragen trafen auf DRAM, weniger Lesevorgänge erreichten den verteilten Speicherdienst, und die Prozessoren verbrachten weniger Zeit mit Adressübersetzungen. Diese Ergebnisse entsprechen den Designänderungen.
Sie zeigen nicht, dass jede qualifizierte Compute-Instanz doppelt so schnell wird. Databricks verwendet die Formulierung „bis zu“, und die drei Ergebnisse unterscheiden sich. Eines verzeichnete einen Durchsatzanstieg von 43 %, während zwei ungefähr das Doppelte der vorherigen Messung erreichten.
Die Zusammensetzung des Workloads bleibt die größte Variable. Cache-sensitive Abfragen mit wiederholtem Zugriff auf einen großen, aber begrenzten Working Set sollten stärker profitieren. Schreibintensive Arbeit, Scans mit geringer Wiederverwendung, Lock-Contention, ineffiziente Abfragen oder netzwerkgebundene Anwendungslogik können die sichtbare Verbesserung begrenzen.
Der frühere lokale Dateicache erfüllte ebenfalls eine nützliche Funktion. Er bot mehr Kapazität als die ursprüngliche Shared-Buffer-Zuweisung und vermied viele Anfragen auf Speicherebene. Das Verlegen heißer Seiten von NVMe in DRAM verbessert den schnellsten Pfad, doch das Entfernen dieser sekundären Ebene verändert das Verhalten, wenn der Working Set den verfügbaren Speicher überschreitet.
Databricks zufolge führt ein Cache Miss auf diesen festen Computes nun von Shared Buffers direkt zum verteilten Speicher. Das wirft eine wichtige Frage für ungewöhnlich große oder wechselnde Workloads auf. Eine höhere Speicher-Trefferrate kann mit einer stärkeren Strafe für Seiten einhergehen, die außerhalb des vergrößerten Buffer Pools liegen.
Die veröffentlichten Endpunkte scheinen profitiert zu haben, weil ihre aktiven Daten gut in die größere Zuweisung passten. Nahezu 100%ige Trefferraten in zwei Beispielen deuten auf starke Lokalität hin. Anwendungen mit geringerer Lokalität könnten ein anderes Verhältnis zwischen schnelleren Treffern und Remote Misses zeigen.
Auch das Verhalten bei Neustarts verdient Aufmerksamkeit. Shared Buffers sind flüchtig; eine neu gestartete Compute-Instanz beginnt daher normalerweise ohne ihren heißen Working Set im Speicher. Databricks dokumentiert separat das automatische Cache-Prewarming, das häufig verwendete Daten bei geplanten Updates erneut befüllt.
Prewarming kann die Cold-Cache-Strafe nach einem Update verringern, Anwendungen können während des Neustarts jedoch weiterhin eine kurze Verbindungsunterbrechung erleben. Treiber, Pools und Retry-Logik müssen dieses Ereignis bewältigen. Cache-Verbesserungen ersetzen nicht die Notwendigkeit resilienter Verbindungen.
Unabhängige Benchmark-Ergebnisse würden die Argumentation stärken. Nützliche Tests würden Datensatzgröße, Anzahl der Verbindungen, Abfrageverteilung, Buffer-Status, Compute-Größe und Latenzperzentile offenlegen. Sie würden außerdem die alten und neuen Cache-Pfade sowohl unter stabilen als auch unter wechselnden Working Sets vergleichen.
Vorerst stützen die Belege eine engere Schlussfolgerung. Die Verbesserung des Lakebase-Postgres-Compute-Caches scheint für die großen Produktionsendpunkte, die Databricks gemessen hat, wirksam zu sein. Das Ausmaß für eine andere Anwendung bleibt eine empirische Frage, die Betreiber mit eigenen Latenz-, Trefferraten-, CPU- und Storage-Lesemetriken beantworten sollten.
Der zentrale Konflikt lautet: fester Speicher gegen Autoscaling
Die aktuelle Veröffentlichung verbessert die einfachere Hälfte von Lakebase, während das serverlose Versprechen des Produkts davon abhängt, Cache-Speicher ohne Neustart von Postgres zu skalieren.
Die Einstellung shared_buffers wird normalerweise vor dem Start von Postgres festgelegt. Eine Änderung erfordert einen Neustart, weil die Datenbank ihren Shared-Memory-Bereich während der Initialisierung anlegt. Dieses Verhalten steht in direktem Konflikt mit einer autoskalierenden Compute-Instanz, deren Speicherkapazität sich während der Verarbeitung von Datenverkehr ändert.
Eine feste Compute-Instanz vermeidet den Konflikt. Databricks kennt die Speichermenge der virtuellen Maschine, weist 75 % Shared Buffers zu, reserviert die entsprechenden Huge Pages und startet Postgres. Die Zuweisung kann über die gesamte Lebensdauer der Maschine unverändert bleiben.
Ein Autoscaling-Endpunkt muss wachsen und schrumpfen. Steigt die Nachfrage, sollte Postgres Buffer-Kapazität gewinnen und der Gast exakt die Menge an Huge Pages erhalten, die für eine effiziente Abbildung erforderlich ist. Sinkt die Nachfrage, müssen beide Ressourcen zurückgegeben werden, ohne aktiven Zustand zu beschädigen oder störende Neustarts zu erzwingen.
Das ist eine wesentlich andere Engineering-Aufgabe. Shared Memory kann Seiten enthalten, die aktive Backends lesen, ändern, anheften oder prüfen. Das Verkleinern der Region erfordert eine sichere Abstimmung mit Cache-Eviction und paralleler Datenbankaktivität.
Databricks erklärt, ein Protokoll entwickelt zu haben, das Huge Pages gemeinsam mit dynamischen Shared Buffers skaliert. Das Unternehmen plant, diese Implementierung in einem zweiten technischen Beitrag zu erläutern. Zudem beabsichtigt es, mit der Open-Source-PostgreSQL-Community an den zugrunde liegenden Mechanismen zu arbeiten.
Bis diese Arbeit ausgeliefert wird, verfügt Lakebase über zwei Cache-Strategien. Große feste Computes erhalten das vergrößerte Shared-Buffer-Design. Autoskalierende Computes verlassen sich weiterhin auf die bestehende Kombination aus konservativ dimensionierten Shared Buffers und dem lokalen Dateicache.
Diese Aufteilung setzt die Positionierung des Produkts unter Druck. Feste Kapazität bietet heute die deutlichste Leistungsverbesserung, während Autoscaling die Flexibilität bietet, die mit einer serverlosen Datenbank verbunden ist. Kunden können noch nicht davon ausgehen, beide Eigenschaften im selben Compute-Modus zu erhalten.
Das macht Autoscaling nicht für jede Bereitstellung unterlegen. Variable oder sporadische Anwendungen können Scale-to-zero und elastische Kapazität höher bewerten als die niedrigstmögliche Cache-Latenz. Ein stabiler, speicherintensiver Produktionsdienst könnte dagegen vorhersehbare feste Ressourcen bevorzugen.
Die Entscheidung hängt auch vom Wachstum des Workloads ab. Feste Computes erfordern, dass Betreiber im Voraus ausreichend Kapazität auswählen. Autoscaling kann Verkehrsschwankungen auffangen, doch der aktuelle Cache-Pfad kann mehr Treffer über lokales NVMe leiten, wenn der Working Set die kleine Shared-Buffer-Zuweisung überschreitet.
Dies ist der eigentliche Wettbewerbstest für die Lakebase-Cache-Performance. Andere verwaltete Postgres-Dienste kombinieren ebenfalls verteilte Persistenz, lokales Caching, Replikate und elastische Ressourcenverwaltung. Die architektonischen Details unterscheiden sich, sodass Benchmark-Schlagzeilen selten eine eindeutige Produktbewertung ermöglichen.
Databricks muss stattdessen zeigen, dass seine Speichertrennung keine vermeidbare Strafe für die Workloads verursacht, auf die das Unternehmen abzielt. Dynamische Shared Buffers würden es Lakebase ermöglichen, sein zustandsloses Compute-Modell beizubehalten und zugleich mehr elastischen Speicher direkt unter die Kontrolle von Postgres zu stellen.
Die Zusammenarbeit mit Upstream könnte die Auswirkungen über Lakebase hinaus erweitern. Dynamische Buffer-Größen sind für containerisierte und elastische Postgres-Umgebungen relevant, in denen sich der zugewiesene Speicher im Zeitverlauf verändert. Databricks hat jedoch weder den in seiner Ankündigung beschriebenen Code noch den Prüfstatus oder den Veröffentlichungspfad publiziert.
Diese Unsicherheit sollte ausdrücklich bleiben. Das Unternehmen hat eine Richtung genannt und erklärt, dass das Autoscaling-Protokoll existiert. Es hat weder ein Veröffentlichungsdatum noch einen unterstützten Compute-Bereich oder Produktionsmessungen für autoskalierende Shared Buffers bereitgestellt.
Der Rollout für feste Computes ist daher sowohl eine Verbesserung als auch eine Vorschau. Er validiert die Mechanismen der Cache-Platzierung und Huge Pages unter stabilen Speicherbedingungen. Die nächste Phase muss beweisen, dass diese Mechanismen einer sich verändernden Maschine folgen können, ohne Verfügbarkeit oder vorhersehbare Leistung zu beeinträchtigen.
Was Lakebase-Nutzer jetzt messen sollten
Die relevante Frage ist nicht, ob der veröffentlichte Benchmark beeindruckend aussieht, sondern ob ein berechtigter Workload schneller wird, ohne eine neue Miss-Strafe zu entwickeln.
Berechtigte Nutzer können zunächst die Konfiguration bestätigen. show shared_buffers zeigt die aktuelle Postgres-Buffer-Zuweisung, während show huge_pages meldet, ob explizite Huge Pages aktiv sind. Ein Databricks-Endpunkt mit 80 Einheiten sollte laut Unternehmensbeispiel 120 GB und on anzeigen.
Die Konfiguration allein belegt keinen Nutzen. Teams sollten Cache-Trefferrate, Storage-GetPage-Aktivität, CPU-Verbrauch, Durchsatz sowie p50- und p99-Abfragelatenz über vergleichbare Verkehrsfenster hinweg vergleichen. Ein Vergleich sollte Bereitstellungen, Datenwachstum, Wartung und Anwendungsänderungen berücksichtigen.
Die Cache-Trefferrate braucht Kontext. Eine Rate nahe 100 % kann darauf hindeuten, dass der aktive Working Set in den Speicher passt. Ohne Betrachtung von Durchsatz und Latenz kann sie aber auch Unterschiede bei Anfragekosten, Abfragehäufigkeit oder Workload-Mix verbergen.
Storage-Lesevorgänge liefern ein weiteres direktes Signal. Ein Rückgang deutet darauf hin, dass mehr Seiten innerhalb von Postgres verbleiben, statt Pageserver zu erreichen. Databricks berichtete in seinem ersten Beispiel von etwa 5,3-mal weniger GetPage-Anfragen, basierend auf dem Rückgang von etwa 8.000 auf 1.500 pro Sekunde.
CPU-Messungen können den Nutzen von Huge Pages und vermiedener Disk-Cache-Verarbeitung sichtbar machen. Ein geringerer CPU-Verbrauch ist jedoch vor allem dann aussagekräftig, wenn er mit stabilem oder höherem Durchsatz einhergeht. Eine ruhige Phase kann sowohl CPU-Nutzung als auch erledigte Arbeit senken, ohne einen Effizienzgewinn widerzuspiegeln.
Teams sollten auch das Neustart- und Aufwärmverhalten prüfen. Geplante Updates lösen Neustarts der Compute-Ressourcen aus, die laut Databricks jedoch normalerweise nur wenige Sekunden dauern. Tests von Verbindungswiederholungen und Tail-Latenzen in diesen Zeitfenstern können operative Effekte sichtbar machen, die Diagramme im stabilen Betrieb übersehen.
Ein konkretes Szenario ist eine transaktionale Anwendung, deren aktive Indizes und häufig abgerufene Zeilen mehrere zehn Gigabyte belegen. In der früheren Konfiguration konnte nur ein kleiner Teil davon in Shared Buffers verbleiben. Viele Treffer landeten im lokalen NVMe-Cache, obwohl DRAM noch ungenutztes Potenzial bot.
Nach dem Update könnte dieser Working Set nahezu vollständig in den vergrößerten Buffer Pool passen. Das Team sollte mit weniger Speicheranfragen, geringerer Leselatenz und reduziertem CPU-Overhead rechnen. Wenn sich diese Signale nicht verändern, dominiert wahrscheinlich ein anderer Engpass.
Ein AI-Agent-Service bietet ein zweites Szenario. Er könnte Gesprächszustände, Tool-Ergebnisse, Job-Status oder Vektormetadaten in Postgres speichern. Spitzen bei parallelen Lesezugriffen können davon profitieren, dass häufig wiederverwendete Seiten im Speicher bleiben; Verbindungszahlen und Abfragemuster bestimmen jedoch weiterhin die Belastung der Backend-Prozesse.
Ingenieurteams, die eine solche Änderung bewerten, benötigen gemeinsame Evidenz statt isolierter Screenshots. Eine durchsuchbare Engineering-Wissensdatenbank kann Benchmark-Bedingungen, Abfragepläne, Konfigurations-Snapshots und Beobachtungen beim Rollout für spätere Vergleiche bewahren.
Die Bewertung sollte auch den Fehlerfall umfassen. Wenn der Working Set die vergrößerten Shared Buffers übersteigt, verfügen feste Compute-Ressourcen nicht mehr über den bisherigen lokalen Dateicache als Zwischenebene. Die Messung der Latenz bei Kaltstarts, großen Scans und plötzlichen Änderungen des Working Sets zeigt, ob Remote-Cache-Misses stärker sichtbar werden.
Keine dieser Prüfungen erfordert, die zentrale Behauptung des Unternehmens zu akzeptieren oder abzulehnen. Sie übersetzen den vorgeschlagenen Mechanismus in beobachtbare Signale. Wenn unter vergleichbarer Last mehr Lesezugriffe Shared Buffers treffen und gleichzeitig CPU-Auslastung sowie Tail-Latenz sinken, funktioniert das Update für diesen Workload.
Bleibt der Durchsatz unverändert, sollten Teams Sperrwartezeiten, Anwendungsnetzwerk, Abfragepläne, Indizes und Schreiblast untersuchen, bevor sie das Ergebnis Lakebase zuschreiben. Eine Cache-Änderung kann nicht jede Ursache für Datenbanklatenz beheben.
Drei Signale werden entscheiden, ob das Cache-Redesign relevant ist
Die Bereitstellung für Autoscaling, unabhängige Workload-Evidenz und Fortschritte im Upstream-PostgreSQL werden bestimmen, ob daraus ein breiter Lakebase-Vorteil wird.
Das erste Signal ist eine Produktionsfreigabe dynamischer Shared Buffers für Autoscaling-Compute-Ressourcen. Databricks muss zeigen, dass die Kapazität der Shared Buffers parallel zum Arbeitsspeicher wachsen und schrumpfen kann, während das Huge-Page-Backing korrekt dimensioniert bleibt. Eine Freigabe mit offengelegter Berechtigung, Rollout-Verhalten und operativen Grenzen würde die architektonische Argumentation des Unternehmens stärken.
Produktionsmessungen sollten diese Freigabe begleiten. Der aussagekräftige Vergleich ist nicht Autoscaling gegenüber einem nicht verwandten Fixed-Benchmark. Er vergleicht denselben elastischen Workload vor und nach dynamischen Buffers, einschließlich Scale-up-Ereignissen, Scale-down-Ereignissen, Cache-Hit-Raten, CPU-Nutzung und p99-Latenz.
Wenn Autoscaling eine vergleichbare Cache-Effizienz ohne störende Neustarts erreicht, wird die vorliegende Analyse überzeugender. Das würde zeigen, dass entkoppeltes Postgres elastische Compute-Ressourcen mit einem großen, von der Engine verwalteten Speicher-Cache kombinieren kann. Eine längere Verzögerung würde den schnellsten Pfad auf feste Kapazität beschränken.
Das zweite Signal sind breitere Benchmark-Nachweise. Databricks hat drei vorteilhafte Produktionsbeispiele veröffentlicht, doch Nutzer benötigen Ergebnisse für unterschiedliche Working-Set-Größen und Abfragemuster. Unabhängige Tests sollten leselastige Transaktionen, gemischte Lese- und Schreibvorgänge, hohe Verbindungszahlen, Kaltstarts und Workloads umfassen, die größer als der verfügbare DRAM sind.
Nachweise konsistenter Gewinne würden den behaupteten Mechanismus stützen. Stark variable Ergebnisse würden die Freigabe nicht entkräften, aber die Gruppe der Anwendungen eingrenzen, die wahrscheinlich profitieren. Eine Verschlechterung bei Cache-Misses würde nach dem Wegfall der lokalen Festplattenebene genauere Aufmerksamkeit erfordern.
Das dritte Signal sind sichtbare Fortschritte im Open-Source-PostgreSQL. Databricks erklärt, bei dynamischen Shared Buffers mit dem Upstream zusammenarbeiten zu wollen. Konkrete Vorschläge, Patches, technische Diskussionen und Feedback von Reviewern würden zeigen, wie viel der Lösung in Postgres selbst gehört.
Eine Upstream-Akzeptanz würde dem Design breitere technische Prüfung verschaffen und es über einen einzelnen Anbieter hinaus nutzbar machen. Sie könnte außerdem die langfristige Lücke zwischen elastischen Cloud-Umgebungen und Postgres-Einstellungen verringern, die für eine feste Maschine konzipiert wurden.
Ein ausbleibendes Upstreaming der Arbeit würde Databricks nicht daran hindern, eine plattformspezifische Implementierung bereitzustellen. Es würde es Außenstehenden jedoch erschweren, Kompatibilität, Wartung und Portabilität einzuschätzen.
Die Verbesserung des Lakebase-Postgres-Compute-Cache liefert bereits messbare Ergebnisse auf ausgewählten festen Compute-Ressourcen. Der wesentlichere Test ist, ob Databricks den Cache dynamisch gestalten kann, ohne die Elastizität zu schwächen, die die Trennung vom Speicher ermöglicht.
Für Teams mit berechtigten Endpoints ist der nächste Schritt unkompliziert: die Einstellungen prüfen, eine stabile Ausgangsbasis erfassen und nach dem Rollout echte Workload-Metriken vergleichen. Autoscaling-Nutzer sollten auf die zweite Engineering-Freigabe achten, bevor sie davon ausgehen, dass dieselben Gewinne gelten. Was ist für Ihre Anwendung heute wichtiger: Leistung mit festem Arbeitsspeicher oder die Freiheit, Kapazität entsprechend der Nachfrage zu skalieren?
