Databricks Lakebase Permite Rastreo de Costos por Branch para Database Sprawl

La promesa de infraestructura unificada de datos/IA siempre fue más fácil de diagramar que de facturar. Databricks Lakebase Parte 3 cierra ese ciclo: una única consulta SQL une datos de propietario en vivo de Backstage de una tabla Postgres operacional a filas de facturación en la nube en system.billing.usage, sin pipelines ETL. El resultado se almacena en el motor SQL de Unity Catalog, que históricamente nunca compartió contexto de consulta con bases de datos OLTP en vivo. La adopción de Lakebase ha crecido a más del doble de la tasa del producto de almacén de datos de Databricks desde GA en junio de 2025.

El aislamiento de compute impulsa la mecánica. Lakebase asigna a cada carga de trabajo su propio envoltorio de compute con escalado automático, para que el portal de desarrollo Backstage y las consultas pesadas de los analistas de FinOps compartan almacenamiento subyacente sin contender por CPU y memoria. En la POC, las consultas de catálogo se ejecutaron en 55–65 ms de extremo a extremo; las búsquedas alcanzaron 2–4 ms. Las consultas analíticas no pueden privar del portal en vivo porque cada consumidor obtiene recursos de escalado automático dedicados. Esta es la consecuencia directa de la adquisición de $1 mil millones de Neon por Databricks en mayo de 2025: el almacenamiento vive en el lake, el compute se escala independientemente por consumidor.

Databricks Lakehouse Federation monta la base de datos Postgres en vivo como un catálogo extranjero dentro de Unity Catalog. Una vez registrado, una única consulta SQL extrae nombres de recursos de la tabla operacional y cargos de DBU de system.billing.usage. Sin script de sincronización Python. Sin actualización de Delta horaria. Sin movimiento de datos. Para entornos efímeros, esto es crítico: cuando un desarrollador crea un branch de base de datos para probar una solicitud de extracción, los datos de facturación y propiedad son instantáneamente consultables. Un enfoque ETL tradicional requeriría aprovisionar nuevos pipelines para cada branch temporal.

Cada PR y branch de característica aparece como un elemento de línea independiente en system.billing.usage, desglosado por branch_id y endpoint_id. El branch de prueba en la POC costó 0.0107 DBU. Treinta branches huérfanos ejecutándose durante un mes no son triviales. Databricks recomienda branches de CI con TTL cortos y expiración automática. Sin controles de ciclo de vida, los endpoints de compute huérfanos se acumulan silenciosamente sin visibilidad a menos que alguien consulte la tabla de facturación.

Un punto de fricción bloquea esto completamente. El conector Postgres de Lakehouse Federation solo admite credenciales de nombre de usuario/contraseña estáticas con autenticación SCRAM-SHA-256. Las identidades de aplicaciones de Lakebase se autentican a través de JWT de OAuth. Estos caminos son incompatibles, por lo que los equipos deben aprovisionar un rol nativo de Postgres separado con credenciales estáticas para Federation, luego administrar la rotación de contraseña independientemente de la identidad de OAuth que usa la aplicación. La separación de seguridad es intencional — Federation no debe ejecutarse como el usuario de la aplicación — pero la carga de rotación recae en el equipo. La compatibilidad nativa con JWT de OAuth eliminaría esta brecha.

El argumento de productividad en torno al branching es mensurable. Eliminar tiempos de espera de aprovisionamiento de entorno y 20–30% del mantenimiento de objetos simulados en conjuntos de pruebas son costos reales de ingeniería. El 0.0107 DBU por branch es el recibo de infraestructura para esa productividad. Los gerentes de ingeniería ahora pueden comparar el gasto de compute dev/test a nivel de sprint contra el compute de producción, desglosado por desarrollador y branch, desde dentro del mismo motor SQL que ejecuta análisis. Esa conversación no ha sido posible con implementaciones estándar de Postgres.

Una hora para crear el rol Postgres estático, conectar la conexión y crear el catálogo extranjero resuelve la brecha de autenticación de Federation. La política de ciclo de vida de branching es el elemento de gobernanza a más largo plazo—la acumulación de branches huérfanos es un problema de costo de movimiento lento que aparece solo después de que los equipos usan branching durante varios sprints.