Databricks LTAP Elimina Pipelines CDC para Analytics con Datos Frescos de Transacciones

Databricks ha publicado un desglose arquitectónico detallado de Lakebase, su oferta serverless Postgres, y LTAP—Lake Transaction & Metadata Protocol. El post se lee más como una autopsia de tres décadas de diseño de bases de datos que como un anuncio de producto. Cada gran dolor de cabeza operacional se remonta a la misma causa raíz: el WAL y los archivos de datos viviendo en la misma máquina.

El problema del monolito no es nuevo, pero Databricks lo nombra con precisión. Cada instancia tradicional de Postgres, MySQL u Oracle mantiene dos cosas en disco local: el write-ahead log (WAL), que hace que los commits sean rápidos mediante adiciones secuenciales, y los archivos de datos, que hacen que las lecturas sean rápidas almacenando el estado actual. Esa coubicación crea costos operacionales en cascada. La durabilidad del commit depende de configuraciones sutiles de disk-flush—el SO puede mentir silenciosamente sobre flushing. Si el disco de la máquina muere, los datos mueren. Escalar lecturas requiere provisionar un clon físico completo, que desestabiliza el primario. Alta disponibilidad significa ejecutar al menos dos copias completas en sincronización, pagando infraestructura 2x+. Las consultas analíticas compiten directamente con la latencia OLTP.

Lakebase rompe ese acoplamiento haciendo que la capa de compute Postgres sea sin estado. El WAL se mueve a SafeKeeper, un servicio de nube distribuido que acepta escritas de quórum. Una transacción es durable en el momento en que el quórum de SafeKeeper la reconoce, sin disco local en el camino. Los archivos de datos se mueven a PageServer, que almacena páginas en almacenamiento de objetos en la nube y las sirve bajo demanda a los nodos de compute. Cualquier instancia de compute Postgres puede conectarse al mismo SafeKeeper y PageServer, por lo que la conmutación por error es un intercambio de puntero en lugar de un clon completo de base de datos. El branching se vuelve instantáneo—solo una bifurcación de puntero de metadatos, no una copia de bytes.

LTAP es la segunda capa. Donde Lakebase desagrega el almacenamiento de formatos Postgres tradicionales, LTAP cambia el formato en sí. Los datos operacionales se almacenan una vez en formato columnar abierto—Delta Lake / Parquet—que tanto Postgres como los engines Lakehouse de Databricks leen directamente. Las consultas analíticas se ejecutan contra la misma capa de almacenamiento en la que las transacciones acaban de escribir: sin pipeline CDC, sin segunda copia, sin lag de replicación. Esto aborda directamente la arquitectura que operan la mayoría de los equipos de datos ejecutando Postgres + Databricks hoy: escrituras transaccionales a Postgres, un pipeline CDC (Debezium, Fivetran, o similar) empujando cambios al lakehouse, y consultas analíticas ejecutándose en datos que están obsoletos por minutos u horas.

HTAP—hybrid transactional/analytical processing—intenta manejar ambas cargas de trabajo en un único engine. Un único engine optimizado para ninguno termina siendo mediocre en ambos. LTAP mantiene engines especializados en su lugar. Postgres maneja OLTP, Spark y el runtime Databricks manejan OLAP, y comparten una capa de almacenamiento común sin interferencia. Por diseño, LTAP enruta analíticas a través de la capa de almacenamiento compartida en lugar de la ruta de compute transaccional, evitando que las dos cargas de trabajo compitan por los mismos recursos.

Para cargas de trabajo de ML e IA, la implicación es datos de features más frescos con menos partes móviles. Los pipelines de features que hoy leen de una réplica OLAP con lag de replicación pueden leer directamente del almacenamiento LTAP a frescura de transacción-committed. Eso elimina tanto el lag como el pipeline como superficies de falla. La capacidad de branching importa para equipos que hacen iteración rápida de esquema—girar una rama para una prueba de migración o reciclaje de modelo no cuesta nada en overhead de copia de datos.

Databricks no ha publicado números de latencia de benchmark para la ruta de escritura de quórum SafeKeeper o penalizaciones de falta de caché PageServer. Los equipos que evalúan Lakebase para cargas de trabajo sensibles a la latencia deben tratar esos como preguntas abiertas hasta que aparezcan estudios de caso de producción. El argumento arquitectónico es sólido; el envolvente operacional a escala queda por demostrarse externamente.

Si estás ejecutando un pipeline CDC de Postgres a Databricks hoy, LTAP es el reemplazo arquitectónico directo—una copia, sin pipeline, analíticas con datos frescos de transacciones.