por Bryan Smith
nOps, un partner de Databricks Built On que gestiona más de 4 mil millones de dólares en gasto anual en la nube, migró su aplicación de producción a Databricks Lakebase. El resultado fue una arquitectura más rápida y sencilla que eliminó la conexión entre su aplicación y sus análisis, y un manual para ISV que buscan hacer lo mismo.
Cada ISV que construye sobre Databricks eventualmente llega a la misma encrucijada arquitectónica: tus análisis viven en el Lakehouse, pero tu aplicación necesita una base de datos relacional para lecturas y escrituras de baja latencia. Así que añades una instancia de Postgres separada (quizás RDS, quizás algo autogestionado) y de repente estás manteniendo pipelines ETL, cron jobs y lógica de detección de cambios solo para mantener dos sistemas sincronizados.
nOps vivió esa realidad durante años. Y luego encontraron una mejor manera.
Para aquellos que no están familiarizados, nOps es una plataforma automatizada de optimización de costos en la nube que gestiona descuentos basados en compromisos en AWS, GCP y Azure. Su enfoque es distintivamente "siempre activo". Monitorean, compran e intercambian compromisos en la nube sobre una base horaria, utilizando machine learning para equilibrar las tasas de ahorro efectivas contra el riesgo de bloqueo de compromisos. El modelo está basado en el rendimiento: nOps solo cobra un porcentaje de los ahorros incrementales que generan.
Es una operación intensiva en datos. Cada hora, nOps analiza patrones de uso en miles de cuentas de clientes, evalúa carteras de compromisos en tres proveedores de nube principales y docenas de servicios, y toma decisiones de compra automatizadas. Además de eso, muestran visibilidad de costos, pronósticos y detección de anomalías a través de una plataforma FinOps centralizada.
La columna vertebral analítica de todo esto ha sido durante mucho tiempo Databricks Lakehouse. Pero la aplicación front-end, la plataforma a la que los clientes inician sesión para ver sus ahorros, gestionar presupuestos y explorar datos de costos, necesitaba algo más.
La arquitectura anterior de nOps era un patrón familiar para los ISV en Databricks. Los análisis avanzados y el cálculo de métricas se ejecutaban en el Lakehouse. Los datos orientados al cliente (configuraciones de cuentas, preferencias de usuario, estado específico del cliente que cambia rápidamente) residían en una base de datos relacional separada impulsada por proveedores de terceros y soluciones caseras.
Las costuras entre estos dos sistemas crearon fricción real. Se requerían trabajos programados y detección de cambios basada en cron para mantener sincronizada la base de datos front-end y el Lakehouse. Los datos que estaban "en vivo" en un sistema podían tardar minutos o más en aparecer en el otro. Y la sobrecarga operativa de gestionar una pila de bases de datos separada, con sus propias preocupaciones de escalado, respaldo y seguridad, desviaba el tiempo de ingeniería de lo que nOps hace mejor: construir automatización de compromisos.
Cuando nOps se expandió de cobertura solo AWS a cobertura multicloud en GCP y Azure a principios de 2026, las crecientes cargas de trabajo tensaron esta arquitectura. El equipo decidió reconstruir la plataforma, centrándose esta vez en su especialidad y eligiendo infraestructura que simplemente funciona.
nOps seleccionó Databricks Lakebase, una base de datos PostgreSQL totalmente administrada e integrada directamente con el Lakehouse, como la columna vertebral OLTP para su nueva plataforma.
Jordan Stein, Director de Producto en nOps, señaló tres factores que hicieron de Lakebase la opción correcta:
Así se ve la nueva arquitectura de nOps:
Lakebase sirve como la base de datos central de Postgres y la única fuente de verdad tanto para la aplicación front-end como para su infraestructura de IA.
Databricks Lakehouse consume continuamente datos de Lakebase para análisis y cálculo de métricas.
La plataforma nOps descubre y muestra automáticamente Databricks Metric Views, de modo que las métricas estandarizadas calculadas en el Lakehouse aparezcan de manera consistente en el front-end.
Los datos fluyen en una dirección, desde Lakebase hacia el Lakehouse para análisis, sin necesidad de escritura directa. Esto mantiene la arquitectura limpia y la fuente de verdad inequívoca.
El resto de la pila sigue el mismo enfoque: Vercel para alojamiento y observabilidad, WorkOS para autenticación, y Databricks para todo lo relacionado con datos.
Jordan Stein recientemente repasó la historia completa de la migración de nOps a Lakebase en una presentación destacada de partners. Mira el video para escuchar cómo fue la transición, qué les sorprendió del rendimiento y cómo la integración con Lakehouse cambió sus flujos de trabajo de ingeniería de datos:
La historia de nOps no es única. Casi todos los ISV que construyen sobre Databricks se enfrentan a la misma tensión entre OLTP y análisis. Lo que vale la pena prestar atención es cuán limpiamente Lakebase lo resuelve.
Elimina el impuesto de sincronización. El código más costoso en la pila de cualquier ISV suele ser el código que mueve datos entre sistemas. La integración nativa de Lakebase con Unity Catalog y la sincronización Delta Lake con un clic reemplazan los pipelines ETL personalizados con infraestructura administrada. Eso es tiempo de ingeniería que recuperas.
Un modelo de gobernanza. Cuando tu base de datos OLTP se registra como un activo de Unity Catalog, obtienes gobernanza unificada, linaje y control de acceso en datos operacionales y analíticos. No más gestión de políticas de seguridad en dos lugares.
La compatibilidad con Postgres significa cero reescritura. Lakebase es PostgreSQL totalmente administrado. Tus bibliotecas existentes, ORMs y herramientas SQL funcionan de inmediato. Se admiten extensiones como pgvector y PostGIS. Migras apuntando tu aplicación a una nueva cadena de conexión, no reescribiendo consultas.
Economía de escala que tiene sentido. El precio basado en el uso con escala a cero significa que no pagas por capacidad inactiva. Para ISV con cargas de trabajo variables (¿y qué ISV no tiene cargas de trabajo variables?) esto impacta directamente en la economía unitaria.
Entrega más rápido. Cuando tu base de datos de aplicación y tu data warehouse son la misma plataforma, desaparece una categoría entera de trabajo de integración. Tu equipo entrega funcionalidades en lugar de mantener la plomería.
nOps es un buen ejemplo de cómo luce un partner innovador de Built On. En lugar de esperar a que Lakebase madure a través de múltiples ciclos de lanzamiento, reconocieron el ajuste arquitectónico temprano, se comprometieron con una migración de producción y ya están viendo resultados: pipelines de datos más rápidos, menor sobrecarga operativa y una mejor experiencia para sus clientes.
Esa disposición a moverse temprano también es estratégicamente inteligente. Al construir sobre Lakebase ahora, nOps tiene una integración más estrecha con la plataforma Databricks que los competidores que todavía están uniendo pilas de bases de datos separadas. Su plataforma es más simple de operar y más rápida de extender.
Explora Lakebase. Si eres un ISV que construye sobre Databricks, o lo estás considerando, obtén más información sobre Lakebase y cómo puede simplificar tu arquitectura.
Explora nOps. Si tu organización busca reducir los costos de la nube en AWS, GCP o Azure sin el riesgo de compromiso, visita nOps para ver cómo su plataforma de optimización automatizada, ahora impulsada por Databricks Lakebase, puede ayudarte.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.