Databricks detalla mejoras en la caché de cómputo de Postgres en Lakebase
Databricks afirma que unos búferes compartidos de Postgres más amplios y el nuevo soporte de memoria con páginas grandes (huge pages) en los nodos de cómputo grandes de Lakebase reducen la latencia y el uso de CPU, con pruebas en producción que muestran mejoras de rendimiento de hasta 2 veces.
Respuesta rápida
¿Qué anunció Databricks sobre la mejora de la caché de cómputo de Postgres en Lakebase?
Databricks afirma que aumentó los búferes compartidos de Postgres al 75% de la DRAM en los nodos de cómputo de tamaño fijo grandes de Lakebase (CU 80 o superior) y añadió soporte dedicado de memoria con páginas grandes, en sustitución de una configuración de caché de archivos local que limitaba los búferes compartidos a cerca de 1 GB. La compañía reporta mejoras de rendimiento en producción de hasta 2 veces, menos lecturas de almacenamiento y menor uso de CPU y latencia.
Claves
- Databricks afirma que elevó los búferes compartidos de Postgres en los nodos de cómputo de tamaño fijo grandes de Lakebase (CU 80 y superior) al 75% de la DRAM disponible, frente al límite anterior de aproximadamente 1 GB, y desactivó la caché de archivos local en esos nodos.
- La compañía afirma haber introducido soporte dedicado de memoria con páginas grandes de 2 MB en toda su infraestructura de máquinas virtuales para reducir la sobrecarga de traducción de memoria generada por los búferes compartidos más amplios.
- Databricks reporta pruebas de referencia que muestran que las páginas grandes redujeron la latencia de lectura en la cola hasta en un 40% aproximadamente y disminuyeron el uso de CPU hasta en un 30% aproximadamente.
- En los ejemplos de producción citados por Databricks, un endpoint registró un rendimiento de bloques accedidos que se duplicó aproximadamente mientras las lecturas en la capa de almacenamiento cayeron unas cinco veces, y otro vio caer el uso de CPU de 20 núcleos a 4.
- Databricks afirma que el despliegue comenzó región por región unas semanas antes de la publicación del 10 de septiembre de 2026 y que una segunda entrada prevista abordará el trabajo sobre el autoescalado de los búferes compartidos.
Qué anunció Databricks
Databricks publicó una entrada de blog el 10 de septiembre de 2026 en la que describe los cambios realizados en la forma en que su servicio Lakebase Postgres almacena en caché los datos en los nodos de cómputo. La publicación, presentada como la primera de una serie, está firmada por David Wein, Sunil Kamath y Haoyu Huang. Databricks afirma que el objetivo es aprovechar de forma más eficiente la DRAM disponible en el cómputo de Lakebase manteniendo más datos en la capa de memoria más rápida de Postgres.
Contexto sobre la configuración de caché
Según Databricks, Lakebase Postgres utiliza un modelo de almacenamiento desagregado, con caché tanto en el almacenamiento distribuido como en el propio nodo de cómputo. En una implementación estándar de Postgres, la base de datos almacena en caché los datos en un área en memoria llamada búferes compartidos, mientras que el sistema operativo almacena en caché por separado esas mismas páginas en su propia caché de páginas, una configuración que, según Databricks, provoca un doble almacenamiento en búfer, de modo que 1 GB de datos en caché puede llegar a consumir 2 GB de RAM. Databricks señala también que los búferes compartidos de Postgres son normalmente un parámetro estático que requiere reiniciar la base de datos para modificarse, lo que la compañía considera un desafío para un sistema sin servidor y con autoescalado.
Para sortear este problema, Databricks afirma haber creado una caché de archivos local, o LFC, que ha estado en funcionamiento en todo el cómputo de Lakebase desde su lanzamiento. La LFC reside en el almacenamiento NVMe local del nodo de cómputo como un nivel secundario detrás de los búferes compartidos, que Databricks había ajustado de forma conservadora, limitándolos a cerca de 1 GB con independencia de la memoria total del cómputo.
Búferes compartidos más amplios y páginas grandes
Databricks afirma haber eliminado ahora ese límite de aproximadamente 1 GB para los nodos de cómputo de tamaño fijo grandes. Para los cómputos con CU de 80 o superior, la compañía indica que desactiva la LFC y fija los búferes compartidos de Postgres en el 75% de la DRAM disponible, manteniendo las páginas de acceso más frecuente en el nivel de memoria más rápido en lugar de recurrir a la caché local, más lenta. Databricks señala que los clientes pueden comprobar la configuración ejecutando "show shared_buffers" en una conexión de Postgres, y que se espera que un endpoint de 80 CU devuelva un valor de 20971520.
Dado que unos búferes compartidos más amplios aumentan la sobrecarga de traducción de memoria en el diseño de un proceso por conexión de Postgres, Databricks afirma haber introducido también soporte dedicado de memoria con páginas grandes (huge pages) de 2 MB en toda su infraestructura de máquinas virtuales, optando por páginas HugeTLB explícitas en lugar de depender de las páginas grandes transparentes, que funcionan de forma no garantizada. La compañía sostiene que esto exigió un soporte coherente desde el nivel del host, pasando por el hipervisor, hasta el núcleo del sistema invitado. Los clientes pueden verificar el ajuste ejecutando "show huge_pages", que según Databricks debería devolver "on" en un endpoint de 80 CU.
Resultados reportados
Databricks afirma que sus pruebas de referencia mostraron que las páginas grandes redujeron la latencia de lectura en la cola hasta en un 40% aproximadamente y disminuyeron el uso de CPU hasta en un 30% aproximadamente. La compañía indica que el despliegue comenzó región por región unas semanas antes de la publicación y cita tres ejemplos de producción medidos tras reinicios del cómputo. En un endpoint grande, Databricks señala que los bloques de Postgres accedidos por segundo se duplicaron y que las lecturas desde la capa de almacenamiento cayeron de unas 8.000 por segundo a unas 1.500, mientras el cliente reportó una latencia p50 y p99 menor que la del día, la semana y el mes anteriores. En un segundo endpoint, Databricks afirma que el rendimiento aumentó alrededor de un 43% y que la tasa de aciertos de la caché de cómputo alcanzó casi el 100%. En un tercero, Databricks señala que el uso de CPU pasó de 20 núcleos a 4 tras el cambio, junto con una duplicación del rendimiento.
Databricks afirma que los cambios actuales se aplican a los cómputos de tamaño fijo, ya que los búferes compartidos aún no pueden escalar de forma dinámica, y que una segunda entrada prevista en la serie abordará su trabajo sobre el autoescalado de los búferes compartidos.
Fuente: Blog de Databricks, "Improving Lakebase Postgres compute cache", publicado el 10 de septiembre de 2026.
Preguntas frecuentes
- ¿En qué consiste el cambio en la caché de cómputo de Postgres en Lakebase anunciado por Databricks?
- Databricks afirma que aumentó los búferes compartidos de Postgres al 75% de la DRAM disponible en los nodos de cómputo de tamaño fijo grandes (CU 80 y superior), en sustitución de una configuración que limitaba los búferes compartidos a cerca de 1 GB y dependía de una caché de archivos local secundaria.
- ¿Qué mejoras de rendimiento reporta Databricks?
- Databricks cita ejemplos de producción con aumentos de rendimiento de entre 1,3 y 2 veces aproximadamente, lecturas en la capa de almacenamiento que caen hasta cinco veces en un endpoint, y un uso de CPU que pasa de 20 núcleos a 4 en otro.
- ¿Cómo abordó Databricks la sobrecarga derivada de unos búferes compartidos más amplios?
- La compañía afirma haber añadido soporte dedicado de memoria con páginas grandes de 2 MB en toda su infraestructura de máquinas virtuales, lo que en sus pruebas de referencia redujo la latencia de lectura en la cola hasta en un 40% aproximadamente y el uso de CPU hasta en un 30% aproximadamente.
- ¿Se aplica este cambio a todos los cómputos de Postgres en Lakebase?
- Databricks afirma que la configuración de búferes compartidos más amplios está actualmente disponible solo para los cómputos de tamaño fijo con CU de 80 o superior, y que una segunda entrada prevista abordará los cómputos con autoescalado.