Databricks anunció el 2 de noviembre la disponibilidad general de Lakebase Postgres en Google Cloud. Lakebase es la base de datos Postgres gestionada y sin servidor de la compañía, pensada para que las cargas transaccionales de una aplicación convivan con la plataforma analítica en lugar de vivir en un silo aparte, y hasta ahora no estaba disponible de forma general en esa nube.
El servicio llega a cinco regiones —europe-west3, us-central1, us-east4, us-west1 y asia-southeast1—, con un acuerdo de nivel de servicio del 99,99 % en configuración de alta disponibilidad multizona y del 99,9 % en zona única. La conectividad privada mediante Private Service Connect de Google Cloud, que permite conectar las aplicaciones desde la red virtual del cliente sin que el tráfico salga a la red pública, está en beta: es la salvedad más importante del anuncio para quien tenga requisitos estrictos de aislamiento de red.
Funcionalmente, Lakebase ofrece escalado automático con reducción a cero cuando no hay tráfico, ramificación instantánea para crear copias sin duplicar datos y probar cambios con seguridad, recuperación a un punto en el tiempo, compatibilidad con las herramientas, controladores y extensiones habituales de Postgres, y un motor de búsqueda compatible con pgvector para aplicaciones que necesiten búsqueda por similitud. La identidad y el control de acceso se gestionan con OAuth de Databricks o con credenciales nativas de Postgres, y la integración con Unity Catalog extiende el mismo gobierno a los datos operacionales y a los analíticos.
El argumento comercial es la eliminación del circuito de ida y vuelta entre la base de datos operacional y el almacén analítico: al compartir la misma base de almacenamiento, desaparecen las tuberías de extracción que hoy mantienen sincronizados ambos mundos. La compañía cita pruebas de carga directa de un terabyte en menos de cinco minutos sin degradar el rendimiento de la aplicación. Son cifras del fabricante y en condiciones que no detalla, así que valen como indicación y no como previsión.
La ventaja de que sea Postgres y no un motor propietario es la que conviene no perder de vista: la compatibilidad con controladores y extensiones estándar es lo que determina si una decisión así es reversible. Una aplicación que hable Postgres normal puede moverse a otro proveedor gestionado si las condiciones cambian; lo que sí ata es el resto —el escalado a cero, la ramificación, la integración con el catálogo—, porque son precisamente las capacidades que no existen en un Postgres cualquiera y de las que un equipo acaba dependiendo.
Para una organización en España, la región europe-west3 (Fráncfort) es el dato operativo relevante: permite mantener los datos dentro de la Unión Europea sin recurrir a una región estadounidense, que sigue siendo el primer filtro en cualquier evaluación con requisitos de protección de datos. El resto del análisis es el habitual en servicios sin servidor: conviene modelar el coste con el patrón de tráfico propio, porque el escalado a cero abarata mucho los entornos intermitentes y encarece poco los constantes, y ahí es donde suele estar la diferencia entre el ahorro prometido y el real.
Más en Dataprix: guía de arquitectura de datos de Dataprix
Fuente: Databricks (blog oficial)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.