Databricks améliore le cache de calcul Lakebase Postgres, mais l’autoscaling reste le véritable test

Databricks améliore les performances du cache de calcul Lakebase Postgres grâce à une nouvelle configuration qui a généré jusqu’à deux fois plus de débit dans ses mesures de production. Ce changement est déjà actif sur les calculs Databricks à taille fixe comptant au moins 80 unités de calcul. Toutefois, le problème le plus difficile reste non résolu : appliquer la même stratégie mémoire aux calculs qui s’étendent et se contractent pendant l’exécution de Postgres.

La mise à jour modifie l’endroit où les pages de base de données fréquemment demandées passent leur temps. Les grands calculs à taille fixe consacrent désormais jusqu’à 75 % de la mémoire disponible aux tampons partagés de Postgres. Ces tampons constituent le cache en mémoire le plus rapide du moteur de base de données. Databricks soutient également cette mémoire avec des huge pages de 2 MB afin de réduire le travail de traduction d’adresses au sein du système d’exploitation.

Cette combinaison cible une tension centrale des bases de données désagrégées. La séparation du stockage durable et du calcul permet des redémarrages rapides, une mise à l’échelle indépendante et un stockage objet économique. Elle accroît toutefois aussi la distance entre une requête en cours d’exécution et les données dont elle a besoin. Amazon Aurora, AlloyDB et d’autres bases de données cloud rencontrent des variantes de ce problème, mais Databricks applique son correctif à l’architecture Neon sous-jacente à Lakebase.

L’amélioration du cache de calcul Lakebase Postgres commence par les calculs fixes

Databricks a déplacé la partie la plus sollicitée du cache Lakebase du disque local vers la mémoire Postgres, mais uniquement sur des machines à taille fixe suffisamment grandes.

Le changement a été rendu public le 9 septembre 2026. Selon la mise à jour du cache de calcul de l’entreprise, il est actif sur les calculs Lakebase à taille fixe comptant au moins 80 unités de calcul. Le déploiement équivalent chez Neon couvre les calculs fixes d’au moins 18 unités de calcul.

Lakebase utilise un stockage désagrégé, ce qui signifie que le calcul Postgres et le stockage durable des données fonctionnent comme des couches distinctes. Un nœud de calcul exécute le moteur de base de données, mais ne détient pas la copie faisant autorité des données. Cette conception permet aux opérateurs de remplacer, redémarrer ou redimensionner le calcul sans déplacer une base de données entière.

Les lectures suivent une hiérarchie. Postgres vérifie d’abord les tampons partagés en DRAM. Si la page est absente, la configuration précédente vérifie un cache de fichiers local stocké sur le disque NVMe du nœud de calcul. Un nouvel échec envoie la requête vers la couche de stockage distribué, où les pageservers reconstruisent et renvoient les pages de base de données.

Ce cache de fichiers local résolvait un problème initial important. Les installations Postgres standard bénéficient normalement à la fois des tampons partagés et du cache de pages du système d’exploitation. Lakebase n’achemine pas les lectures de pages distantes via un système de fichiers local conventionnel ; il ne peut donc pas dépendre de cette seconde couche habituelle.

Databricks et Neon ont donc conçu le cache de fichiers local comme un substitut élastique. Il pouvait occuper une capacité au-delà de l’allocation statique des tampons Postgres et s’ajuster avec le calcul serverless. Cette organisation prenait en charge l’autoscaling sans obliger Postgres à redimensionner les tampons partagés pendant son exécution.

Cependant, la configuration précédente plafonnait les tampons partagés à environ 1 GB. La majeure partie de la capacité restante du cache de calcul, qui pouvait atteindre 75 % de la DRAM, était attribuée au cache de fichiers local. Sur les grandes machines, cet équilibre envoyait de nombreuses lectures pourtant cacheables vers NVMe plutôt que vers la mémoire.

La nouvelle configuration de calcul fixe retire le cache de fichiers local de ce chemin. Elle attribue 75 % de la DRAM aux tampons partagés, conservant un ensemble de travail bien plus important au sein de Postgres. Selon l’annonce, un endpoint Databricks de 80 unités devrait afficher 120 GB lorsqu’un administrateur exécute show shared_buffers.

L’accès à la DRAM évite les entrées et sorties disque requises par le cache local. Il donne aussi à Postgres une connaissance directe des pages mises en cache et de leur utilisation. Un cache du système d’exploitation ou une couche disque distincte dispose de moins d’informations sur l’état de la base de données lorsqu’il doit décider quelle page évincer.

C’est le sens immédiat de l’amélioration du cache de calcul Lakebase Postgres. Il ne s’agit ni d’un nouvel index, ni d’un planificateur de requêtes, ni d’un format de stockage. Databricks a modifié l’allocation mémoire et les mécanismes de mémoire virtuelle entourant le moteur d’exécution Postgres existant.

La portée est importante. Les déploiements à taille fixe peuvent allouer les tampons partagés au démarrage, car leur plafond de mémoire reste connu. Les endpoints avec autoscaling ne peuvent pas faire la même hypothèse. Leur mémoire disponible évolue selon la demande de charge de travail, tandis que le paramètre Postgres standard reste statique après le démarrage.

C’est pourquoi cette première version est significative sans être complète. Databricks a montré qu’une utilisation plus directe de la mémoire peut améliorer les grands endpoints Lakebase. L’entreprise n’a pas encore livré la même conception pour le modèle opérationnel serverless qui rend Postgres désagrégé attrayant.

Pourquoi les performances du cache Lakebase sont devenues prioritaires

La séparation du stockage apporte de la flexibilité opérationnelle, mais chaque échec de cache révèle les coûts de latence et de CPU dissimulés par cette flexibilité.

Postgres traditionnel regroupe généralement le moteur de requêtes, le journal de transactions et les fichiers de base de données sur une seule machine ou un stockage étroitement connecté. Le système d’exploitation peut conserver les pages de fichiers récemment consultées dans son cache de pages. Postgres conserve également certaines pages dans les tampons partagés.

Cette organisation peut dupliquer des données en mémoire. Databricks donne l’exemple d’une machine dotée de 4 GB de RAM et de 1 GB attribué aux tampons partagés. Lire 1 GB via le système de fichiers peut laisser une autre copie dans le cache du système d’exploitation, consommant 2 GB pour mettre en cache 1 GB de pages de base de données.

Lakebase modifie ce chemin. Son architecture de stockage divise le système entre un calcul Postgres sans état et un service de stockage durable. Les safekeepers répliquent les enregistrements du journal de transactions, tandis que les pageservers reconstruisent les versions des pages et les persistent dans le stockage objet.

L’architecture permet au calcul d’évoluer indépendamment des données stockées. Elle prend en charge des fonctionnalités telles que le scale-to-zero, le branching rapide, les réplicas de lecture et le basculement sans copier une base de données entière. Ces avantages reposent sur le maintien de l’état durable hors du nœud de calcul.

Pourtant, le calcul sans état a toujours besoin d’un état proche pendant le traitement des requêtes. Les applications accèdent de manière répétée aux index, pages de tables, enregistrements de catalogue et autres structures. Si ces pages restent en DRAM, les lectures s’achèvent dans la partie de la hiérarchie offrant la plus faible latence.

Un échec dans les tampons partagés emprunte un chemin plus long. Le cache NVMe local est plus rapide que le stockage distant, mais nécessite toujours un accès disque et un traitement logiciel supplémentaire. Un échec à ce niveau atteint le pageserver, ajoutant potentiellement du trafic réseau et du travail de reconstruction des pages.

La pression qui en résulte pèse sur les équipes utilisant de grandes instances Lakebase pour des applications sensibles à la latence. Ces clients provisionnent une mémoire importante, mais l’ancien plafond de 1 GB des tampons partagés empêchait Postgres d’utiliser l’essentiel de cette mémoire via son chemin de cache le plus rapide.

Le décalage devient plus visible à mesure que l’ensemble de travail augmente. Un ensemble de travail est la collection de pages auxquelles une application accède fréquemment sur une période donnée. Lorsqu’il dépasse le petit cache mémoire, les requêtes se déversent vers des couches plus lentes, même si la machine dispose de suffisamment de DRAM.

Databricks avait besoin d’une meilleure réponse, car Lakebase sert désormais des charges de travail opérationnelles, et pas seulement des tâches analytiques. Les applications destinées aux utilisateurs se préoccupent de la latence de queue, qui reflète les requêtes les plus lentes à l’extrémité d’une distribution de latence. Les moyennes peuvent rester acceptables tandis que les requêtes p99 créent encore des pauses visibles.

Les applications d’IA exercent également une pression inégale sur les bases de données opérationnelles. Un agent peut déclencher des rafales de récupérations, d’écritures, de points de contrôle et d’appels d’outils concurrents. Un comportement de cache prévisible devient plus important lorsque le trafic arrive par grappes plutôt que dans un flux régulier de requêtes.

Cela ne signifie pas que toutes les charges de travail bénéficient de la même manière. Un jeu de données qui tient déjà dans l’allocation précédente de tampons partagés a moins de marge d’amélioration. Une charge de travail dominée par les scans et présentant peu de réutilisation des pages peut continuer à atteindre les niveaux de cache inférieurs, quelle que soit la taille des tampons.

Les meilleurs candidats sont les grands endpoints dotés d’ensembles de travail réutilisables qui dépassaient l’ancienne limite de 1 GB. Leur mémoire existante peut désormais contenir davantage de pages actives directement dans Postgres. C’est pourquoi Databricks a présenté des exemples de production plutôt que de promettre un doublement universel.

Les performances du cache Lakebase dépendent donc autant de la forme de la charge de travail que de la taille de la machine. La nouvelle configuration supprime un goulot d’étranglement architectural. Elle n’annule pas les règles fondamentales qui régissent la localité du cache, la conception des requêtes, l’indexation ou la contention mémoire.

Les huge pages rendent le pool de tampons plus important praticable

Attribuer davantage de mémoire à Postgres créerait sa propre surcharge si Lakebase ne réduisait pas aussi le coût de mappage de cette mémoire entre les processus de base de données.

Postgres utilise une architecture fondée sur les processus. Chaque connexion active reçoit généralement un processus backend, et chaque backend mappe la région des tampons partagés dans son espace d’adressage virtuel. Le système d’exploitation maintient des entrées de table de pages qui traduisent ces adresses virtuelles en emplacements de mémoire physique.

Les pages mémoire Linux standard font généralement 4 KB. Avec cette taille de page, 1 GB de tampons partagés exige 262,144 entrées de table de pages pour chaque processus mappant cette région. Databricks calcule que 32 GB de tampons partagés répartis sur 512 backends peuvent nécessiter environ 4,3 milliards d’entrées.

L’entreprise estime que ces entrées consommeraient environ 32 GB de tables de pages simplement pour mapper un cache de 32 GB. Il s’agit d’une illustration extrême de la manière dont une allocation de tampons plus importante peut déplacer la surcharge ailleurs. Une capacité de cache accrue n’est pas automatiquement utile lorsque la gestion de la mémoire consomme trop de RAM et de temps CPU.

Le processeur maintient également un translation lookaside buffer, ou TLB. Ce cache matériel stocke les traductions récentes d’adresses virtuelles vers des adresses physiques. Une page de données peut être présente dans la mémoire Postgres tout en imposant au CPU une pénalité pour la localiser après un échec de TLB.

Les huge pages réduisent cette pression en mappant la mémoire par unités plus grandes. Lakebase utilise des pages HugeTLB explicites de 2 MB pour la nouvelle configuration de calcul fixe. Chaque huge page couvre 512 fois plus de mémoire qu’une page standard de 4 KB, réduisant du même facteur le nombre d’entrées de mappage requises.

PostgreSQL expose déjà des contrôles de huge pages du système d’exploitation. Sa documentation sur les ressources explique que les huge pages explicites peuvent réduire la surcharge associée aux grandes régions contiguës de mémoire partagée. Cet avantage est particulièrement pertinent lorsque shared_buffers devient très important.

La virtualisation complique la mise en œuvre. Lakebase exécute Postgres dans de légères machines virtuelles invitées sur des hôtes bare-metal. La traduction d’adresses traverse donc à la fois les couches invitées et hôtes. Les huge pages doivent rester soutenues de manière cohérente sur l’hôte, l’hyperviseur et l’invité afin de préserver leur bénéfice attendu.

Databricks indique avoir ajouté une prise en charge dédiée des huge pages dans l’ensemble de cette pile. Les grandes machines virtuelles à taille fixe démarrent avec une quantité prédéterminée de huge pages. Après l’initialisation de Postgres, le système de calcul libère la capacité dont la base de données n’a pas besoin.

L’entreprise a choisi des pages HugeTLB explicites plutôt que les transparent huge pages. Les transparent huge pages permettent au système d’exploitation de promouvoir automatiquement la mémoire, mais ce comportement repose sur un effort maximal. La réservation explicite donne à l’environnement de base de données un contrôle plus strict de la disponibilité et de l’organisation des pages.

Lors de tests de performance Databricks, les huge pages ont réduit la latence de lecture en queue de distribution jusqu’à environ 40 %. L’utilisation du CPU a diminué jusqu’à environ 30 %. Il s’agit de mesures de l’entreprise, et non de garanties indépendantes valables pour chaque charge de travail Lakebase.

Cette distinction est importante, car les huge pages n’expliquent pas à elles seules l’intégralité de l’amélioration rapportée. Deux changements sont intervenus simultanément : davantage de données sont restées dans les buffers partagés, et l’accès à cette région plus vaste a nécessité moins de traductions de pages. Les charges de travail peuvent bénéficier de ces deux mécanismes dans des proportions différentes.

Un administrateur peut vérifier le paramètre déployé via Postgres. L’exécution de show huge_pages doit renvoyer on pour un endpoint Lakebase éligible de 80 unités. Associé à la valeur de shared_buffers, cela permet de confirmer directement si la nouvelle configuration a bien atteint un compute.

Ce mécanisme explique aussi pourquoi une simple augmentation de shared_buffers ne constitue pas une réponse complète pour les déploiements Postgres classiques. La mémoire réservée à la base de données doit coexister avec les connexions, les opérations de requête, les tâches de maintenance et les besoins du système d’exploitation. Une allocation importante peut créer de nouvelles contraintes si le système environnant n’est pas conçu pour la supporter.

Databricks contrôle les machines virtuelles, les images de compute, le chemin de cache et le protocole de stockage. Ce contrôle de bout en bout lui permet de coordonner la réservation de huge pages avec le démarrage de Postgres. Une équipe gérant elle-même son infrastructure devrait régler ces couches indépendamment et valider le résultat sur sa propre charge de travail.

Le fonctionnement du cache Lakebase est donc plus complexe que « utiliser davantage de RAM ». L’amélioration dépend du placement des données chaudes dans la bonne région mémoire, de l’efficacité du mappage de cette région et du maintien de suffisamment de mémoire pour tout ce qui se situe hors du buffer pool.

Les résultats en production montrent des gains, pas une référence universelle

Databricks fait état d’améliorations importantes sur trois endpoints de production, mais les exemples publiés n’établissent pas une moyenne de performance pour l’ensemble de la plateforme.

Le premier exemple a reçu la nouvelle configuration vers 06:10 UTC le 11 août. Le nombre de blocs Postgres consultés par seconde a doublé, une mesure que Databricks a utilisée comme indicateur de débit. Les requêtes de stockage GetPage sont passées d’environ 8 000 par seconde à environ 1 500.

Le client a également signalé une baisse de la latence médiane et p99 par rapport au jour, à la semaine et au mois précédents. La publication ne fournit ni les valeurs de latence sous-jacentes, ni la définition de la charge de travail, ni la combinaison de requêtes, ni un environnement de comparaison contrôlé. Les lecteurs devraient considérer cette observation comme un résultat de production plutôt que comme un benchmark standardisé.

Un deuxième endpoint a changé vers 01:30 UTC le 14 août. Son débit rapporté a augmenté d’environ 43 %, tandis que son taux de succès du cache de compute a approché 100 %. Après le déploiement, les requêtes étaient servies presque entièrement depuis les buffers partagés.

Le troisième endpoint a changé le 15 août. Databricks indique que la consommation de CPU est passée de 20 cœurs à quatre, que le taux de succès du cache a approché 100 % et que le débit mesuré a doublé. La réduction par cinq de l’utilisation du CPU se démarque, mais la publication publique ne précise pas si toutes les conditions externes de charge de travail sont restées constantes.

Pris ensemble, ces exemples étayent un mécanisme crédible. Davantage de requêtes ont atteint la DRAM, moins de lectures ont sollicité le service de stockage distribué et les processeurs ont consacré moins de temps à la traduction d’adresses. Ces résultats correspondent aux changements de conception.

Ils ne démontrent pas que chaque compute éligible devient deux fois plus rapide. Databricks emploie la formulation « jusqu’à », et les trois résultats varient. L’un a enregistré une hausse de débit de 43 %, tandis que deux autres ont atteint environ le double de la mesure antérieure.

La composition de la charge de travail reste la variable la plus importante. Les requêtes sensibles au cache, avec des accès répétés à un ensemble de travail important mais limité, devraient davantage bénéficier de l’amélioration. Les charges très orientées écriture, les scans à faible réutilisation, la contention sur les verrous, les requêtes inefficaces ou la logique applicative limitée par le réseau peuvent réduire le gain visible.

L’ancien cache de fichiers local effectuait lui aussi un travail utile. Il offrait une capacité supérieure à l’allocation initiale de buffers partagés et évitait de nombreuses requêtes vers la couche de stockage. Déplacer les pages chaudes du NVMe vers la DRAM améliore le chemin le plus rapide, mais supprimer ce niveau secondaire modifie le comportement lorsque l’ensemble de travail dépasse la mémoire disponible.

Databricks indique qu’un échec de cache passe désormais des buffers partagés au stockage distribué sur ces computes fixes. Cela soulève une question importante pour les charges de travail exceptionnellement volumineuses ou changeantes. Un taux de succès mémoire plus élevé peut coexister avec une pénalité plus forte pour les pages situées hors du buffer pool agrandi.

Les endpoints publiés semblent avoir bénéficié du fait que leurs données actives tenaient bien dans l’allocation plus importante. Des taux de succès proches de 100 % dans deux exemples suggèrent une forte localité. Les applications présentant moins de localité pourraient afficher un équilibre différent entre des succès plus rapides et des échecs distants.

Le comportement au redémarrage mérite également l’attention. Les buffers partagés sont temporaires ; un compute nouvellement démarré commence donc normalement sans son ensemble de travail chaud en mémoire. Databricks documente séparément le préchauffage automatique du cache, qui recharge les données fréquemment utilisées lors des mises à jour planifiées.

Le préchauffage peut réduire la pénalité d’un cache froid après une mise à jour, mais les applications peuvent toujours subir une brève interruption de connexion durant le redémarrage. Les drivers, pools et mécanismes de nouvelle tentative doivent gérer cet événement. Les améliorations de cache ne suppriment pas le besoin de résilience des connexions.

Des résultats de benchmarks indépendants renforceraient l’argumentation. Des tests utiles indiqueraient la taille du jeu de données, le nombre de connexions, la distribution des requêtes, l’état des buffers, la taille du compute et les percentiles de latence. Ils compareraient aussi les anciens et nouveaux chemins de cache avec des ensembles de travail stables comme évolutifs.

Pour l’instant, les éléments disponibles appuient une conclusion plus limitée. L’amélioration du cache de compute Lakebase Postgres semble efficace pour les grands endpoints de production mesurés par Databricks. L’ampleur du gain pour une autre application reste une question empirique à laquelle les opérateurs doivent répondre avec leurs propres mesures de latence, de taux de succès, de CPU et de lectures de stockage.

Le principal conflit oppose la mémoire fixe à l’autoscaling

La version actuelle améliore la partie la plus simple de Lakebase, tandis que la promesse serverless du produit dépend de la capacité à redimensionner la mémoire du cache sans redémarrer Postgres.

Le paramètre shared_buffers est normalement choisi avant le démarrage de Postgres. Le modifier impose un redémarrage, car la base de données établit sa région de mémoire partagée lors de l’initialisation. Ce comportement entre directement en conflit avec un compute autoscaling dont la capacité mémoire évolue pendant le traitement du trafic.

Un compute fixe évite ce conflit. Databricks connaît la quantité de mémoire de la machine virtuelle, alloue 75 % aux buffers partagés, réserve les huge pages correspondantes et démarre Postgres. L’allocation peut rester inchangée pendant toute la durée de vie de la machine.

Un endpoint autoscaling doit pouvoir croître et décroître. Lorsque la demande augmente, Postgres doit obtenir davantage de capacité de buffer et l’instance invitée doit recevoir la quantité exacte de huge pages nécessaire pour la mapper efficacement. Lorsque la demande baisse, les deux ressources doivent être restituées sans corrompre l’état actif ni imposer de redémarrages perturbateurs.

Il s’agit d’une tâche d’ingénierie sensiblement différente. La mémoire partagée peut contenir des pages que des backends actifs lisent, modifient, épinglent ou inspectent. Réduire la région exige une coordination sûre avec l’éviction du cache et l’activité concurrente de la base de données.

Databricks affirme avoir développé un protocole qui adapte les huge pages en parallèle des buffers partagés dynamiques. L’entreprise prévoit d’expliquer cette implémentation dans une seconde publication technique. Elle entend aussi collaborer avec la communauté PostgreSQL open source sur les mécanismes sous-jacents.

Tant que ce travail n’est pas disponible, Lakebase dispose de deux stratégies de cache. Les grands computes fixes reçoivent la conception avec buffers partagés agrandis. Les computes autoscaling continuent de s’appuyer sur la combinaison existante de buffers partagés dimensionnés de manière prudente et du cache de fichiers local.

Cette séparation met sous pression le positionnement du produit. La capacité fixe offre aujourd’hui l’amélioration de performance la plus nette, tandis que l’autoscaling apporte la flexibilité associée à une base de données serverless. Les clients ne peuvent pas encore supposer qu’ils bénéficient des deux caractéristiques dans le même mode de compute.

Cela ne rend pas l’autoscaling inférieur pour chaque déploiement. Les applications variables ou intermittentes peuvent accorder davantage de valeur au scale-to-zero et à la capacité élastique qu’à la latence de cache la plus faible possible. Un service de production stable et gourmand en mémoire peut préférer des ressources fixes prévisibles.

La décision dépend également de la croissance de la charge de travail. Les computes fixes exigent que les opérateurs choisissent à l’avance une capacité suffisante. L’autoscaling peut absorber les variations de trafic, mais le chemin de cache actuel peut faire transiter davantage de succès par le NVMe local lorsque l’ensemble de travail dépasse la faible allocation de buffers partagés.

C’est le véritable test concurrentiel des performances du cache Lakebase. D’autres services Postgres managés combinent eux aussi durabilité distribuée, cache local, réplicas et gestion élastique des ressources. Les détails architecturaux diffèrent ; les chiffres de benchmark mis en avant permettent donc rarement d’établir un classement clair des produits.

Databricks doit plutôt démontrer que sa séparation du stockage n’impose pas de pénalité évitable aux charges de travail qu’il cible. La mise à disposition de buffers partagés dynamiques permettrait à Lakebase de conserver son modèle de compute sans état tout en plaçant davantage de mémoire élastique sous le contrôle direct de Postgres.

La collaboration avec l’amont pourrait étendre l’impact au-delà de Lakebase. Le dimensionnement dynamique des buffers est pertinent pour les environnements Postgres conteneurisés et élastiques, où la mémoire attribuée évolue au fil du temps. Toutefois, Databricks n’a pas encore publié le code, le statut de revue ou le chemin de publication mentionnés dans son annonce.

Cette incertitude doit rester explicite. L’entreprise a indiqué une orientation et affirme que le protocole d’autoscaling existe. Elle n’a pas communiqué de date de disponibilité, de plage de computes prise en charge ou de mesures de production concernant les buffers partagés autoscaling.

Le déploiement pour les computes fixes est donc à la fois une amélioration et un aperçu. Il valide les mécanismes de placement de cache et de huge pages dans des conditions de mémoire stables. La prochaine étape devra démontrer que ces mécanismes peuvent suivre l’évolution d’une machine sans sacrifier la disponibilité ni la prévisibilité des performances.

Ce que les utilisateurs de Lakebase doivent mesurer maintenant

La question pertinente n’est pas de savoir si le benchmark publié paraît impressionnant, mais si une charge de travail éligible devient plus rapide sans introduire une nouvelle pénalité d’échec de cache.

Les utilisateurs éligibles peuvent d’abord confirmer la configuration. show shared_buffers révèle l’allocation actuelle des buffers Postgres, tandis que show huge_pages indique si les huge pages explicites sont actives. Un endpoint Databricks de 80 unités devrait afficher 120 GB et on, selon l’exemple de l’entreprise.

La configuration seule n’établit pas la valeur. Les équipes doivent comparer le taux de succès du cache, l’activité de stockage GetPage, la consommation de CPU, le débit et la latence de requête p50 et p99 sur des fenêtres de trafic équivalentes. La comparaison doit tenir compte des déploiements, de la croissance des données, de la maintenance et des changements applicatifs.

Le taux de succès du cache mérite d’être contextualisé. Un taux proche de 100 % peut indiquer que l’ensemble de travail actif tient en mémoire. Il peut également masquer des différences de coût des requêtes, de fréquence des requêtes ou de composition de la charge s’il est examiné sans le débit et la latence.

Les lectures de stockage fournissent un autre signal direct. Leur baisse suggère que davantage de pages restent dans Postgres au lieu d’atteindre les pageservers. Databricks a signalé environ 5,3 fois moins de requêtes GetPage dans son premier exemple, sur la base de la baisse d’environ 8 000 à 1 500 par seconde.

Les mesures CPU peuvent révéler le bénéfice des huge pages et de l’évitement de la gestion du cache disque. Toutefois, une baisse de l’utilisation du CPU est surtout utile lorsqu’elle s’accompagne d’un débit stable ou accru. Une période calme peut réduire à la fois le CPU et le travail achevé sans refléter un gain d’efficacité.

Les équipes devraient également examiner le comportement lors des redémarrages et de la phase de remise en température. Les mises à jour planifiées déclenchent des redémarrages de compute, même si Databricks indique qu’ils ne prennent généralement que quelques secondes. Tester les nouvelles tentatives de connexion et la latence de queue autour de ces fenêtres peut révéler des effets opérationnels que les graphiques en régime établi ne montrent pas.

Un scénario concret est celui d’une application transactionnelle dont les index actifs et les lignes fréquemment consultées occupent des dizaines de gigaoctets. Dans l’ancienne configuration, seule une petite partie pouvait rester dans les buffers partagés. De nombreux accès descendaient vers le cache NVMe local malgré de la capacité DRAM inutilisée.

Après la mise à jour, cet ensemble de travail pourrait tenir presque entièrement dans le pool de buffers agrandi. L’équipe devrait constater moins de requêtes de stockage, une latence de lecture plus faible et une charge CPU réduite. Si ces indicateurs ne changent pas, un autre goulot d’étranglement domine probablement.

Un service d’agent d’IA offre un second scénario. Il peut stocker dans Postgres l’état des conversations, les résultats d’outils, l’état des tâches ou des métadonnées vectorielles. Des lectures simultanées par à-coups peuvent bénéficier du maintien en mémoire des pages fréquemment réutilisées, mais le nombre de connexions et les schémas de requêtes déterminent toujours la pression exercée sur les processus backend.

Les ingénieurs qui évaluent ce type de changement ont besoin d’éléments de preuve partagés, et non de captures d’écran isolées. Une base de connaissances d’ingénierie consultable peut conserver les conditions de benchmark, les plans de requêtes, les instantanés de configuration et les observations de déploiement pour des comparaisons ultérieures.

L’évaluation devrait aussi inclure le cas d’échec. Si l’ensemble de travail dépasse les buffers partagés agrandis, les computes fixes ne disposent plus de l’ancien cache de fichiers local comme niveau intermédiaire. Mesurer la latence lors de démarrages à froid, de scans volumineux et de changements soudains de l’ensemble de travail montrera si les échecs distants deviennent plus visibles.

Aucune de ces vérifications ne nécessite d’accepter ou de rejeter l’affirmation phare de l’entreprise. Elles traduisent le mécanisme proposé en signaux observables. Si davantage de lectures atteignent les buffers partagés tandis que le CPU et la latence de queue diminuent sous une demande équivalente, la mise à jour fonctionne pour cette charge de travail.

Si le débit reste stable, les équipes devraient examiner les attentes de verrous, le réseau applicatif, les plans de requêtes, les index et la pression d’écriture avant d’attribuer le résultat à Lakebase. Une modification du cache ne peut pas résoudre toutes les sources de latence de base de données.

Trois signaux détermineront si la refonte du cache compte

La livraison de l’autoscaling, des preuves indépendantes sur les charges de travail et les progrès de PostgreSQL en amont détermineront si cela devient un avantage étendu pour Lakebase.

Le premier signal est une version de production des buffers partagés dynamiques pour les computes avec autoscaling. Databricks doit démontrer que la capacité des buffers partagés peut augmenter et diminuer avec la mémoire tout en conservant un dimensionnement correct du support par pages géantes. Une version présentant les critères d’éligibilité, le comportement de déploiement et les limites opérationnelles renforcerait l’argument architectural de l’entreprise.

Des mesures en production devraient accompagner cette version. La comparaison utile n’oppose pas l’autoscaling à un benchmark fixe sans rapport. Il s’agit de la même charge de travail élastique avant et après les buffers dynamiques, y compris les événements de montée en capacité, de réduction de capacité, les taux de cache hit, l’utilisation CPU et la latence p99.

Si l’autoscaling atteint une efficacité de cache comparable sans redémarrages perturbateurs, l’analyse actuelle s’en trouvera renforcée. Cela montrerait que Postgres désagrégé peut combiner un compute élastique avec un grand cache mémoire géré par le moteur. Un retard prolongé laisserait la voie la plus rapide limitée à une capacité fixe.

Le deuxième signal est un ensemble de preuves de benchmark plus large. Databricks a publié trois exemples de production favorables, mais les utilisateurs ont besoin de résultats couvrant différentes tailles d’ensembles de travail et différents schémas de requêtes. Des tests indépendants devraient inclure des transactions majoritairement en lecture, des lectures et écritures mixtes, un nombre élevé de connexions, des démarrages à froid et des charges de travail supérieures à la DRAM disponible.

Des preuves de gains constants conforteraient le mécanisme revendiqué. Des résultats très variables n’invalideraient pas la version, mais ils réduiraient l’ensemble des applications susceptibles d’en bénéficier. Une régression lors des cache misses nécessiterait une attention accrue après la suppression du niveau de disque local.

Le troisième signal est un progrès visible dans PostgreSQL open source. Databricks indique prévoir de collaborer en amont sur les buffers partagés dynamiques. Des propositions concrètes, des correctifs, des discussions techniques et les retours des reviewers révéleraient quelle part de la solution doit être intégrée à Postgres lui-même.

Une acceptation en amont soumettrait la conception à un examen technique plus large et la rendrait utile au-delà d’un seul fournisseur. Elle pourrait aussi réduire l’écart à long terme entre les environnements cloud élastiques et les paramètres Postgres conçus autour d’une machine fixe.

L’absence d’intégration en amont n’empêcherait pas Databricks de livrer une implémentation spécifique à sa plateforme. Elle rendrait toutefois plus difficile pour les observateurs externes d’évaluer la compatibilité, la maintenance et la portabilité.

L’amélioration du cache de compute Lakebase Postgres produit déjà des résultats mesurables sur certains computes fixes sélectionnés. Le test le plus conséquent consiste à déterminer si Databricks peut rendre le cache dynamique sans affaiblir l’élasticité apportée par la séparation du stockage.

Pour les équipes utilisant des endpoints éligibles, la prochaine action est simple : vérifier les paramètres, capturer une baseline stable et comparer les métriques de charge de travail réelles après le déploiement. Pour les utilisateurs de l’autoscaling, attendez la deuxième version d’ingénierie avant de supposer que les mêmes gains s’appliquent. Qu’est-ce qui compte le plus pour votre application aujourd’hui : les performances avec une mémoire fixe ou la liberté d’adapter la capacité à la demande ?