¿Qué es PostgreSQL sin servidor?

Serverless PostgreSQL (Postgres) es un modelo de base de datos en la nube totalmente administrado que desacopla el cómputo y el almacenamiento. Esto permite que cada uno se escale de forma independiente y automática en función de la demanda. En lugar de administrar los servidores de bases de datos directamente, las aplicaciones interactúan con sistemas que aprovisionan automáticamente recursos de cómputo en respuesta a la carga de trabajo y los reducen cuando están inactivos.

Por el contrario, en los entornos tradicionales de Postgres, los equipos deben dimensionar la infraestructura con anticipación, estimar los requisitos de capacidad y administrar el escalado a lo largo del tiempo. Esto suele provocar un sobredimensionamiento, un desperdicio de costos por inactividad y cuellos de botella en el rendimiento cuando la demanda supera la capacidad disponible.

Serverless Postgres elimina gran parte de esa complejidad operativa mediante:

• La eliminación del aprovisionamiento de servidores y la administración de la infraestructura
• La eliminación de la necesidad de realizar una planificación de capacidad manual
• El cobro únicamente por el uso activo en lugar del cómputo inactivo

El término «serverless» puede ser engañoso, ya que no significa que las aplicaciones se ejecuten sin servidores ni infraestructura. Los sistemas subyacentes siguen existiendo, pero están abstraídos y son administrados por completo por el proveedor de la nube. Las tareas como la configuración, el escalado y el mantenimiento del servidor son prácticamente invisibles para los usuarios y no es necesario configurarlas ni mantenerlas directamente.

PostgreSQL tradicional frente a serverless

Las arquitecturas de PostgreSQL han evolucionado con el tiempo, pasando de modelos de infraestructura aprovisionada a diseños más dinámicos y nativos de la nube.

Postgres tradicional ejecuta recursos de cómputo fijos de forma continua, independientemente de la carga de trabajo. El escalado requiere intervención manual o umbrales preconfigurados, lo que genera costos constantes incluso cuando la base de datos está inactiva.

Serverless Postgres introdujo un modelo diferente. Los recursos de cómputo se aprovisionan bajo demanda, escalando automáticamente con la actividad de la carga de trabajo y reduciéndose a cero cuando no están en uso. La facturación se basa en el consumo real en lugar de la capacidad reservada.

Serverless Postgres también se puede utilizar junto con plataformas de cómputo serverless como Databricks SQL, lo que permite que las consultas analíticas se ejecuten de forma independiente y, al mismo tiempo, accedan a los mismos datos subyacentes dentro de una arquitectura de lakehouse unificada.

Este cambio es posible gracias a modificaciones arquitectónicas, como las capas de almacenamiento desacopladas y la orquestación de cómputo bajo demanda, que permiten que los recursos se escalen de forma independiente y respondan dinámicamente a la actividad de la carga de trabajo.

Las diferencias clave incluyen:

La próxima evolución: la arquitectura de lakebase

A medida que las arquitecturas de bases de datos evolucionan, surge un tercer modelo que se basa en serverless Postgres al tiempo que aborda sus limitaciones. Este enfoque a veces se denomina arquitectura de lakebase.

Serverless Postgres mejora la escalabilidad y reduce la complejidad operativa, pero por lo general sigue estando separado de los sistemas analíticos. Esta separación a menudo requiere el movimiento, la duplicación o la sincronización de datos entre las bases de datos operativas y las plataformas de análisis.

Las arquitecturas de lakebase están cambiando la forma en que pensamos sobre el almacenamiento y el procesamiento de datos. Combinan la potencia de las bases de datos transaccionales con la flexibilidad de una base de lakehouse, lo que crea una plataforma única donde las cargas de trabajo tanto operativas como analíticas pueden ejecutarse juntas. Esto significa que, en lugar de tener sistemas separados para diferentes tareas, todo se puede hacer en una plataforma de datos compartida. El resultado es una menor duplicación de datos y una forma mucho más sencilla de acceder a ellos y utilizarlos. Al unificar todo, las arquitecturas de lakebase facilitan la administración y el análisis de los datos, lo que puede conducir a una mejor toma de decisiones y operaciones más eficientes.

Cómo funciona la arquitectura de lakebase

Las arquitecturas de lakebase se basan en los patrones de serverless Postgres al tiempo que introducen una integración más estrecha con el almacenamiento en la nube y las plataformas de datos.

Los componentes clave incluyen:

• Cómputo y almacenamiento desacoplados
  El cómputo no tiene estado y se escala de forma independiente, mientras que el almacenamiento sigue siendo persistente y distribuido.
• Cómputo efímero
  Los recursos de cómputo se activan para procesar consultas y se reducen cuando están inactivos, lo que permite la elasticidad sin necesidad de mantener una infraestructura siempre activa.
• Sistemas de almacenamiento basados en registros
  Los cambios en los datos se capturan como un registro continuo, que se puede utilizar para reconstruir el estado de la base de datos y admitir funciones como la ramificación, la recuperación y el acceso basado en el tiempo.
• El almacenamiento de objetos como base
  Los datos duraderos se almacenan en un almacenamiento de objetos en la nube, lo que permite la escalabilidad, la durabilidad y la alineación con las arquitecturas de lakehouse.
• Plano de control y orquestación
  Una capa de control administra el escalado, el enrutamiento y los eventos del ciclo de vida, coordinando el cómputo y el almacenamiento de forma dinámica.

Por qué es importante

Al combinar capacidades transaccionales y analíticas en una base compartida, las arquitecturas de lakebase pueden:

• Reducir o eliminar la duplicación de datos entre sistemas
• Permitir análisis casi en tiempo real sobre datos operativos
• Simplificar la arquitectura de datos al consolidar la infraestructura
• Admitir cargas de trabajo emergentes, incluidas las aplicaciones de AI que requieren acceso tanto transaccional como analítico

Este cambio refleja una transición desde la optimización de sistemas individuales hacia su unificación dentro de una sola arquitectura de datos.

Cómo funciona la arquitectura de serverless Postgres

Serverless Postgres se basa en una arquitectura nativa de la nube que separa el cómputo y el almacenamiento en capas independientes. Este principio de diseño fundamental mejora la eficiencia y la flexibilidad al permitir que cada componente se escale de forma independiente.

Una característica clave de esta arquitectura es el comportamiento de escalado a cero. Cuando no se ejecuta ninguna consulta, el sistema suspende automáticamente los recursos de cómputo. Cuando se emite una nueva consulta, el cómputo se reactiva. Esto introduce un breve retraso conocido como latencia de inicio en frío, que puede variar desde milisegundos hasta varios segundos, según el proveedor y la configuración.

Otra capacidad importante es la ramificación de bases de datos, que a menudo se implementa mediante técnicas de copia en escritura. La ramificación permite a los equipos crear entornos de bases de datos aislados para desarrollo, pruebas o preproducción sin duplicar datos. Los cambios realizados en una rama no afectan a la base de datos original, lo que permite una iteración más rápida y una experimentación más segura.

Principales proveedores de serverless Postgres

Las ofertas de serverless Postgres reflejan diferentes etapas en la evolución desde las bases de datos aprovisionadas hasta las arquitecturas totalmente nativas de la nube. Los primeros servicios administrados introdujeron el escalado automático dentro de las arquitecturas de bases de datos existentes. Los diseños nativos de la nube más recientes están creados para admitir agentes de AI, aplicaciones en tiempo real y cargas de trabajo operativas modernas. Estos sistemas desacoplan por completo el cómputo y el almacenamiento, e introducen capacidades que son difíciles de lograr en modelos anteriores, como el escalado rápido, la ramificación y una gestión de recursos más flexible. Neon y Databricks Lakebase se basan en esta base, diseñados para las demandas de aplicaciones orientadas a la AI y sistemas basados en agentes.

• Databricks Lakebase
  Una base de datos operativa basada en la arquitectura de lakebase que amplía serverless Postgres al integrar bases de datos transaccionales con una base de lakehouse. Diseñado para las demandas de los agentes de AI, las aplicaciones en tiempo real y las cargas de trabajo operativas modernas, Databricks Lakebase permite que las cargas de trabajo operativas y analíticas compartan una plataforma de datos común. Los casos de uso incluyen el almacenamiento del estado de los agentes de AI, el soporte de aplicaciones transaccionales y la entrega de información analítica directamente en aplicaciones y flujos de trabajo. El resultado es un menor movimiento de datos y un acceso más consistente en todos los casos de uso.
• Amazon Aurora Serverless v2
  Un servicio administrado compatible con Postgres dentro de AWS que proporciona escalado automático detallado sin necesidad de reiniciar la base de datos. Aurora Serverless v2 está diseñado para cargas de trabajo empresariales y se integra estrechamente con los servicios de AWS para redes, seguridad y monitoreo. Aunque reduce la complejidad operativa, el comportamiento de escalado y el aislamiento de recursos aún pueden reflejar las limitaciones de la infraestructura subyacente.
• Neon
  Una arquitectura lakebase basada en un modelo de cómputo y almacenamiento totalmente desacoplado con almacenamiento basado en registros. Neon admite el escalado a cero y la ramificación de bases de datos, lo que permite una creación rápida de entornos y flujos de trabajo de desarrollo más dinámicos.

Para cargas de trabajo de análisis y procesamiento de datos, el cómputo serverless también está disponible en plataformas como Databricks SQL. Aunque no es una base de datos transaccional (OLTP), estos sistemas proporcionan ejecución de consultas serverless para análisis y pueden funcionar junto con sistemas basados en Postgres.

Raíces de código abierto y opciones nativas de la nube

Postgres es un sistema de base de datos relacional de código abierto ampliamente utilizado. Las ofertas de Postgres serverless se basan en esta base y conservan una compatibilidad total con el ecosistema de Postgres en general, que incluye extensiones, herramientas de línea de comandos como psql, ORMs comunes y más.

Las implementaciones difieren en qué medida el sistema subyacente es abierto o propietario. Algunos proveedores, como Neon, se basan en infraestructura de código abierto y exponen más de su arquitectura a la comunidad. Otros, como Amazon Aurora Serverless, son servicios gestionados propietarios que abstraen gran parte de la implementación subyacente.

Independientemente del enfoque, la mayoría de las soluciones de Postgres serverless buscan mantener una compatibilidad total con Postgres al tiempo que añaden capacidades nativas de la nube como el escalado automático, la ramificación de bases de datos y las operaciones gestionadas.

Estas diferencias pueden influir en la visibilidad y el control que tienen los equipos sobre el rendimiento y el costo. Los sistemas basados en código abierto pueden ofrecer mayor transparencia y flexibilidad, mientras que los servicios gestionados propietarios suelen priorizar la facilidad de uso y la simplicidad operativa.

Modelos de precios y compensaciones de rendimiento

Al evaluar Postgres serverless para cargas de trabajo de producción, es importante comprender cómo influyen los modelos de precios y las características de rendimiento en el costo, la latencia y el comportamiento general del sistema.

Precios basados en el uso: lo que realmente está pagando

La mayoría de los proveedores de Postgres serverless cobran en función de tres dimensiones principales:

• Cómputo: Normalmente se mide en función de los recursos utilizados durante la ejecución de consultas, como el tiempo de vCPU o los segundos de ACU
• Almacenamiento: Se factura en función de la cantidad de datos almacenados, normalmente en GB al mes
• Transferencia de datos: Cargos por el movimiento de datos hacia dentro y fuera de la base de datos, según la región y la configuración de la red

Dado que el cómputo se aprovisiona bajo demanda, los costos se escalan con la actividad de la carga de trabajo. Esto hace que los precios de serverless se adapten bien a aplicaciones con tráfico variable o impredecible.

Muchos proveedores ofrecen niveles gratuitos que son útiles para el desarrollo, las pruebas y las cargas de trabajo a pequeña escala. Estos niveles suelen incluir límites en el uso de cómputo, el almacenamiento o el tiempo de ejecución activo, lo que los hace menos adecuados para cargas de trabajo de producción o aplicaciones con tráfico sostenido.

Aunque los precios de serverless pueden ser eficientes para cargas de trabajo variables, no siempre son la opción de menor costo. En casos con cargas de trabajo de alto tráfico y siempre activas o consultas de larga duración, los costos totales pueden superar los de una instancia de base de datos aprovisionada con capacidad fija.

Inicios en frío, escalado y confiabilidad en producción

Una de las principales consideraciones de rendimiento en Postgres serverless es la latencia de inicio en frío. Cuando una base de datos se ha escalado a cero, el cómputo debe reactivarse antes de que se puedan ejecutar las consultas. Esto introduce un retraso que puede variar desde unos 100 milisegundos hasta varios segundos, según el proveedor y la configuración.

Varias opciones de mitigación pueden reducir el impacto de los inicios en frío:

• Enviar pings periódicos de "keep-alive" para evitar la suspensión total
• Configurar un límite mínimo de cómputo para mantener los recursos parcialmente activos
• Elegir proveedores que minimicen o eliminen los inicios en frío mediante el diseño arquitectónico

Los sistemas serverless también dependen del escalado automático para gestionar las cargas de trabajo cambiantes. Los recursos de cómputo pueden escalarse en respuesta a un mayor volumen de consultas y, en algunos casos, escalar las réplicas de lectura de forma independiente para admitir el acceso concurrente. Esta elasticidad es especialmente útil para aplicaciones con picos de tráfico impredecibles.

Para las cargas de trabajo de producción, la disponibilidad y la tolerancia a fallos son consideraciones críticas. La mayoría de los proveedores gestionados de Postgres serverless replican datos en múltiples zonas de disponibilidad y ofrecen funciones integradas de copia de seguridad y recuperación. Sin embargo, las garantías de nivel de servicio y el comportamiento de recuperación varían según el proveedor, por lo que es importante revisar y verificar la cobertura de SLA antes de su uso en producción.

Características como el comportamiento de inicio en frío y el escalado automático hacen que Postgres serverless sea muy adecuado para cargas de trabajo con tráfico variable, pero pueden introducir compensaciones para aplicaciones sensibles a la latencia o siempre activas.

Casos de uso y limitaciones de Postgres serverless

Postgres serverless y la arquitectura lakebase responden a diferentes necesidades de carga de trabajo. Comprender qué modelo se adapta a su caso de uso puede ayudar a evitar complejidades y costos innecesarios.

Las siguientes pautas pueden ayudar a determinar si Postgres serverless o la arquitectura lakebase es la opción adecuada para su carga de trabajo.

Adecuado para Postgres serverless

• La mayoría de las cargas de trabajo OLTP

Mejor opción para la arquitectura lakebase:

• Desarrollo e implementación de agentes de IA
• Cargas de trabajo variables o con picos de actividad
• Entornos de desarrollo, pruebas y preproducción
• Startups que optimizan costos y reducen la sobrecarga operativa
• Aplicaciones serverless o basadas en edge
• Flujos de trabajo de CI/CD con creación rápida de entornos
• Aplicaciones SaaS multiinquilino (ramificación y escalado automático)

Para las cargas de trabajo que requieren un rendimiento más consistente o disponibilidad siempre activa, la arquitectura lakebase aborda estas necesidades replanteando cómo se coordinan el cómputo y el almacenamiento en una plataforma de datos compartida.

Cómo empezar con Postgres serverless

Empezar con Postgres serverless suele implicar un proceso de configuración sencillo:

1. Elija un proveedor en función de los requisitos de su carga de trabajo, el comportamiento de escalado y las preferencias del ecosistema
2. Cree una instancia de base de datos a través de la consola o la API del proveedor
3. Configure una cadena de conexión con credenciales, región y ajustes de acceso
4. Conéctese utilizando un cliente Postgres estándar, un ORM o la herramienta de línea de comandos psql

Aunque la configuración es relativamente sencilla, las decisiones iniciales pueden tener un impacto profundo en el rendimiento general y la durabilidad. Las consideraciones para la primera implementación deben incluir:

• Establecer un nivel mínimo de cómputo si la latencia de inicio en frío es una preocupación
• Configurar un agrupador de conexiones (connection pooler) para gestionar conexiones concurrentes en entornos serverless o edge
• Habilitar copias de seguridad y recuperación a un punto en el tiempo para proteger contra la pérdida de datos
• Revisar los ajustes de escalado y tiempo de espera para asegurarse de que se alineen con los patrones de tráfico previstos

Postgres serverless se puede utilizar junto con plataformas de cómputo serverless como Databricks SQL para análisis e ingeniería de datos. Esta separación permite que las consultas analíticas se ejecuten de forma independiente del procesamiento transaccional, mientras siguen operando sobre los mismos datos subyacentes.

Para los equipos que gestionan datos operativos junto con análisis, las arquitecturas emergentes como Databricks Lakebase amplían este enfoque al unificar las cargas de trabajo transaccionales y analíticas en una plataforma de datos compartida. Esto reduce el movimiento de datos y simplifica la forma en que se accede a los datos a través de los sistemas.

¿Es la arquitectura lakebase el Postgres serverless adecuado para usted?

Postgres serverless simplifica las operaciones de la base de datos al eliminar gran parte de la gestión de la infraestructura y alinear el costo de manera más precisa con el uso real. Dado que el cómputo y el almacenamiento están desacoplados, los recursos se ajustan a la demanda. Para los equipos con cargas de trabajo más exigentes, la arquitectura lakebase amplía aún más esta base.

Es importante evaluar cuidadosamente estas compensaciones. La previsibilidad del rendimiento, el costo a escala y factores como la latencia de inicio en frío y la gestión de conexiones varían según la carga de trabajo.

La elección del proveedor es fundamental. Las diferencias en el comportamiento de inicio en frío, los modelos de precios, la granularidad de escalado y la adaptación al ecosistema pueden tener un impacto significativo en los resultados. Para las cargas de trabajo de análisis e ingeniería de datos, plataformas como Databricks SQL ofrecen ejecución de consultas serverless. Los equipos también pueden explorar cómo se extiende este modelo a las cargas de trabajo operativas a través de la visita guiada del producto Databricks Lakebase.

A medida que las arquitecturas de bases de datos siguen evolucionando, la arquitectura lakebase unifica las cargas de trabajo operativas y analíticas en una base de datos compartida.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original