O que é o PostgreSQL Serverless?

O PostgreSQL (Postgres) Serverless é um modelo de banco de dados em nuvem totalmente gerenciado que desacopla computação e armazenamento. Isso permite que cada um seja dimensionado de forma independente e automática com base na demanda. Em vez de gerenciar servidores de banco de dados diretamente, os aplicativos interagem com sistemas que provisionam recursos de computação automaticamente em resposta à carga de trabalho e os reduzem quando ociosos.

Em ambientes Postgres tradicionais, por outro lado, as equipes precisam dimensionar a infraestrutura com antecedência, estimar os requisitos de capacidade e gerenciar o escalonamento ao longo do tempo. Isso geralmente resulta em superprovisionamento, desperdício de custos com ociosidade e gargalos de desempenho quando a demanda excede a capacidade disponível.

O Postgres Serverless elimina grande parte dessa sobrecarga ao:

• Eliminar o provisionamento de servidores e o gerenciamento de infraestrutura
• Remover a necessidade de planejamento manual de capacidade
• Cobrar apenas pelo uso ativo em vez de computação ociosa

O termo “serverless” pode ser enganoso, pois não significa que os aplicativos funcionem sem servidores ou infraestrutura. Os sistemas subjacentes ainda existem, mas são abstraídos e totalmente gerenciados pelo provedor de nuvem. Tarefas como configuração do servidor, escalonamento e manutenção são amplamente invisíveis para os usuários e não precisam ser configuradas ou mantidas diretamente.

PostgreSQL tradicional vs. serverless

As arquiteturas do PostgreSQL evoluíram ao longo do tempo, passando de modelos de infraestrutura provisionada para designs mais dinâmicos e nativos da nuvem.

As implantações do Postgres tradicional executam recursos de computação fixos continuamente, independentemente da carga de trabalho. O escalonamento exige intervenção manual ou limites pré-configurados, com custos sempre ativos gerados mesmo quando o banco de dados está ocioso.

O Postgres Serverless introduziu um modelo diferente. Os recursos de computação são provisionados sob demanda, escalando automaticamente com a atividade da carga de trabalho e reduzindo a zero quando não estão em uso. O faturamento é baseado no consumo real, e não na capacidade reservada.

O Postgres Serverless também pode ser usado junto com plataformas de computação serverless, como o Databricks SQL, permitindo que consultas analíticas sejam executadas de forma independente, enquanto ainda acessam os mesmos dados subjacentes em uma arquitetura lakehouse unificada.

Essa mudança é possibilitada por alterações arquitetônicas, como camadas de armazenamento desacopladas e orquestração de computação sob demanda, que permitem que os recursos escalem de forma independente e respondam dinamicamente à atividade da carga de trabalho.

As principais diferenças incluem:

A próxima evolução: arquitetura lakebase

À medida que as arquiteturas de banco de dados evoluem, surge um terceiro modelo que se baseia no Postgres Serverless ao mesmo tempo em que aborda suas limitações. Essa abordagem às vezes é chamada de arquitetura lakebase.

O Postgres Serverless melhora a escalabilidade e reduz a sobrecarga operacional, mas normalmente permanece separado dos sistemas analíticos. Essa separação geralmente exige movimentação, duplicação ou sincronização de dados entre bancos de dados operacionais e plataformas de análise.

As arquiteturas lakebase estão mudando a forma como pensamos sobre armazenamento e processamento de dados. Elas combinam o poder dos bancos de dados transacionais com a flexibilidade de uma base lakehouse, criando uma única plataforma onde as cargas de trabalho operacionais e analíticas podem ser executadas juntas. Isso significa que, em vez de ter sistemas separados para tarefas diferentes, tudo pode ser feito em uma única plataforma de dados compartilhada. O resultado é menos dados duplicados e uma maneira muito mais simples de acessar e usar os dados. Ao unificar tudo, as arquiteturas lakebase facilitam o gerenciamento e a análise de dados, o que pode levar a uma melhor tomada de decisões e a operações mais eficientes.

Como funciona a arquitetura lakebase

As arquiteturas lakebase baseiam-se em padrões do Postgres Serverless, ao mesmo tempo em que introduzem uma integração mais estreita com armazenamento em nuvem e plataformas de dados.

Os principais componentes incluem:

• Computação e armazenamento desacoplados
  A computação é stateless e escala de forma independente, enquanto o armazenamento permanece persistente e distribuído.
• Computação efêmera
  Os recursos de computação são iniciados para processar consultas e reduzidos quando ociosos, permitindo elasticidade sem a necessidade de manter uma infraestrutura sempre ativa.
• Sistemas de armazenamento baseados em log
  As alterações de dados são capturadas como um log contínuo, que pode ser usado para reconstruir o estado do banco de dados e dar suporte a recursos como ramificação, recuperação e acesso baseado em tempo.
• Armazenamento de objetos como base
  Os dados duráveis são armazenados em armazenamento de objetos na nuvem, permitindo escalabilidade, durabilidade e alinhamento com arquiteturas lakehouse.
• Plano de controle e orquestração
  Uma camada de controle gerencia o escalonamento, o roteamento e os eventos de ciclo de vida, coordenando a computação e o armazenamento de forma dinâmica.

Por que isso é importante

Ao combinar recursos transacionais e analíticos em uma base compartilhada, as arquiteturas lakebase podem:

• Reduzir ou eliminar a duplicação de dados entre sistemas
• Permitir análises quase em tempo real em dados operacionais
• Simplificar a arquitetura de dados consolidando a infraestrutura
• Oferecer suporte a cargas de trabalho emergentes, incluindo aplicativos de AI que exigem acesso transacional e analítico

Essa mudança reflete uma transição da otimização de sistemas individuais para a unificação deles em uma única arquitetura de dados.

Como funciona a arquitetura do Postgres Serverless

O Postgres Serverless é construído em uma arquitetura nativa da nuvem que separa a computação e o armazenamento em camadas independentes. Esse princípio de design fundamental melhora a eficiência e a flexibilidade, permitindo que cada componente escale de forma independente.

Um recurso fundamental dessa arquitetura é o comportamento de escala a zero (scale-to-zero). Quando nenhuma consulta está em execução, o sistema suspende automaticamente os recursos de computação. Quando uma nova consulta é feita, a computação é reativada. Isso introduz um pequeno atraso conhecido como latência de inicialização a frio (cold start), que pode variar de milissegundos a vários segundos, dependendo do provedor e da configuração.

Outro recurso importante é a ramificação de banco de dados (database branching), frequentemente implementada usando técnicas de copy-on-write. A ramificação permite que as equipes criem ambientes de banco de dados isolados para desenvolvimento, teste ou staging sem duplicar dados. As alterações feitas em uma ramificação não afetam o banco de dados original, permitindo uma iteração mais rápida e experimentação mais segura.

Principais provedores de Postgres Serverless

As ofertas de Postgres Serverless refletem diferentes estágios na evolução de bancos de dados provisionados para arquiteturas totalmente nativas da nuvem. Os primeiros serviços gerenciados introduziram o escalonamento automático nas arquiteturas de banco de dados existentes. Os designs nativos da nuvem mais recentes são construídos para dar suporte a agentes de AI, aplicativos em tempo real e cargas de trabalho operacionais modernas. Esses sistemas desacoplam totalmente a computação e o armazenamento e introduzem recursos difíceis de alcançar em modelos anteriores, como escalonamento rápido, ramificação e gerenciamento de recursos mais flexível. O Neon e o Databricks Lakebase são construídos sobre essa base, projetados para as demandas de aplicativos focados em AI e sistemas baseados em agentes.

• Databricks Lakebase
  Um banco de dados operacional construído na arquitetura lakebase que estende o Postgres Serverless ao integrar bancos de dados transacionais com uma base lakehouse. Projetado para as demandas de agentes de AI, aplicativos em tempo real e cargas de trabalho operacionais modernas, o Databricks Lakebase permite que cargas de trabalho operacionais e analíticas compartilhem uma plataforma de dados comum. Os casos de uso incluem o armazenamento do estado do agente de AI, a alimentação de aplicativos transacionais e o fornecimento de insights analíticos diretamente em aplicativos e fluxos de trabalho. O resultado é menos movimentação de dados e um acesso mais consistente entre os casos de uso.
• Amazon Aurora Serverless v2
  Um serviço gerenciado compatível com Postgres dentro da AWS que fornece escalonamento automático refinado sem a necessidade de reiniciar o banco de dados. O Aurora Serverless v2 foi projetado para cargas de trabalho corporativas e se integra perfeitamente aos serviços da AWS para rede, segurança e monitoramento. Embora reduza a sobrecarga operacional, o comportamento de escalonamento e o isolamento de recursos ainda podem refletir as restrições da infraestrutura subjacente.

Para cargas de trabalho de análise e processamento de dados, a computação serverless também está disponível em plataformas como o Databricks SQL. Embora não sejam bancos de dados transacionais (OLTP), esses sistemas oferecem execução de consultas serverless para análise e podem operar junto com sistemas baseados em Postgres.

Origens open-source e opções nativas de nuvem

O Postgres é um sistema de banco de dados relacional open-source amplamente utilizado. As ofertas de Postgres serverless são desenvolvidas sobre essa base e mantêm total compatibilidade com o ecossistema mais amplo do Postgres, que inclui extensões, ferramentas de linha de comando como o psql, ORMs comuns e muito mais.

As implementações diferem em relação a quanto do sistema subjacente é aberto ou proprietário. Alguns provedores, como o Neon, são desenvolvidos em infraestrutura open-source e expõem mais de sua arquitetura para a comunidade. Outros, como o Amazon Aurora Serverless, são serviços gerenciados proprietários que abstraem grande parte da implementação subjacente.

Independentemente da abordagem, a maioria das soluções de Postgres serverless visa manter a compatibilidade total com o Postgres, ao mesmo tempo em que adiciona recursos nativos de nuvem, como escalabilidade automática, ramificação de banco de dados e operações gerenciadas.

Essas diferenças podem influenciar a visibilidade e o controle que as equipes têm sobre o desempenho e os custos. Sistemas baseados em open-source podem oferecer maior transparência e flexibilidade, enquanto serviços gerenciados proprietários costumam priorizar a facilidade de uso e a simplicidade operacional.

Modelos de preços e trade-offs de desempenho

Ao avaliar o Postgres serverless para cargas de trabalho de produção, é importante entender como os modelos de preços e as características de desempenho influenciam o custo, a latência e o comportamento geral do sistema.

Preço baseado no uso: pelo que você realmente está pagando

A maioria dos provedores de Postgres serverless cobra com base em três dimensões principais:

• Computação: Geralmente medida com base nos recursos usados durante a execução da consulta, como tempo de vCPU ou segundos de ACU
• Armazenamento: Cobrado com base na quantidade de dados armazenados, geralmente em GB por mês
• Transferência de dados: Cobranças pela movimentação de dados para dentro e para fora do banco de dados, dependendo da região e da configuração da rede

Como a computação é provisionada sob demanda, os custos escalam de acordo com a atividade da carga de trabalho. Isso torna a definição de preço serverless ideal para aplicativos com tráfego variável ou imprevisível.

Muitos provedores oferecem níveis gratuitos que são úteis para desenvolvimento, testes e cargas de trabalho de pequena escala. Esses níveis geralmente incluem limites no uso de computação, armazenamento ou tempo de execução ativo, o que os torna menos adequados para cargas de trabalho de produção ou aplicativos com tráfego constante.

Embora a definição de preço serverless possa ser eficiente para cargas de trabalho variáveis, ela nem sempre é a opção de menor custo. Em casos de cargas de trabalho de alto tráfego e sempre ativas ou consultas de longa execução, os custos totais podem exceder os de uma instância de banco de dados provisionada com capacidade fixa.

Cold starts, escalabilidade e confiabilidade de produção

Uma das principais considerações de desempenho no Postgres serverless é a latência de cold start. Quando um banco de dados é reduzido a zero, a computação deve ser reativada antes que as consultas possam ser executadas. Isso introduz um atraso que pode variar de cerca de 100 milissegundos a vários segundos, dependendo do provedor e da configuração.

Várias opções de mitigação podem reduzir o impacto dos cold starts:

• Enviar pings periódicos de "keep-alive" para evitar a suspensão total
• Configurar um limite mínimo de computação para manter os recursos parcialmente ativos
• Escolher provedores que minimizem ou eliminem cold starts por meio do design arquitetônico

Os sistemas serverless também dependem do escalonamento automático para lidar com mudanças nas cargas de trabalho. Os recursos de computação podem ser escalados verticalmente em resposta ao aumento do volume de consultas e, em alguns casos, escalar réplicas de leitura de forma independente para oferecer suporte ao acesso simultâneo. Essa elasticidade é especialmente útil para aplicativos com picos de tráfego imprevisíveis.

Para cargas de trabalho de produção, a disponibilidade e a tolerância a falhas são considerações críticas. A maioria dos provedores gerenciados de Postgres serverless replica dados em várias zonas de disponibilidade e oferece recursos integrados de backup e recuperação. No entanto, as garantias de nível de serviço e o comportamento de recuperação variam de acordo com o provedor, por isso é importante analisar e verificar a cobertura de SLA antes do uso em produção.

Recursos como o comportamento de cold start e o escalonamento automático tornam o Postgres serverless ideal para cargas de trabalho com tráfego variável, mas podem introduzir trade-offs para aplicativos sensíveis à latência ou sempre ativos.

Casos de uso e limitações do Postgres serverless

O Postgres serverless e a arquitetura lakebase atendem a diferentes necessidades de carga de trabalho. Entender qual modelo se adapta ao seu caso de uso pode ajudar a evitar complexidade e custos desnecessários.

As diretrizes a seguir podem ajudar a determinar se o Postgres serverless ou a arquitetura lakebase é a escolha certa para sua carga de trabalho.

Ideal para Postgres serverless

• A maioria das cargas de trabalho OLTP

Mais adequado para arquitetura lakebase:

• Desenvolvimento e implantação de agentes de IA
• Cargas de trabalho variáveis ou com picos de demanda
• Ambientes de desenvolvimento, teste e staging
• Startups que buscam otimização de custos e redução de sobrecarga operacional
• Aplicativos serverless ou baseados em edge
• Fluxos de trabalho de CI/CD com criação rápida de ambientes
• Aplicativos SaaS multi-tenant (ramificação e escalonamento automático)

Para cargas de trabalho que exigem um desempenho mais consistente ou disponibilidade sempre ativa, a arquitetura lakebase atende a essas necessidades repensando como a computação e o armazenamento são coordenados em uma plataforma de dados compartilhada.

Como começar a usar o Postgres serverless

Começar a usar o Postgres serverless geralmente envolve um processo de configuração simples:

1. Escolha um provedor com base nos requisitos de sua carga de trabalho, comportamento de escalonamento e preferências de ecossistema
2. Crie uma instância de banco de dados por meio do console ou da API do provedor
3. Configure uma string de conexão com credenciais, região e configurações de acesso
4. Conecte-se usando um cliente Postgres padrão, ORM ou a ferramenta de linha de comando psql

Embora a configuração seja relativamente simples, as escolhas iniciais podem ter um impacto profundo no desempenho geral e na durabilidade. As considerações para a primeira implantação devem incluir:

• Definir um nível mínimo de computação se a latência de cold start for uma preocupação
• Configurar um pooler de conexões para gerenciar conexões simultâneas em ambientes serverless ou edge
• Habilitar backups e recuperação point-in-time para proteger contra perda de dados
• Analisar as configurações de escalonamento e tempo limite (timeout) para garantir que estejam alinhadas com os padrões de tráfego esperados

O Postgres serverless pode ser usado junto com plataformas de computação serverless, como o Databricks SQL, para análise e engenharia de dados. Essa separação permite que as consultas analíticas sejam executadas de forma independente do processamento transacional, enquanto ainda operam nos mesmos dados subjacentes.

Para equipes que gerenciam dados operacionais junto com análises, arquiteturas emergentes como o Databricks Lakebase estendem essa abordagem unificando cargas de trabalho transacionais e analíticas em uma plataforma de dados compartilhada. Isso reduz a movimentação de dados e simplifica a forma como os dados são acessados entre os sistemas.

A arquitetura lakebase é o Postgres serverless certo para você?

O Postgres serverless simplifica as operações de banco de dados ao remover grande parte do gerenciamento de infraestrutura e alinhar os custos de forma mais precisa com o uso real. Como a computação e o armazenamento são desacoplados, os recursos se ajustam à demanda. Para equipes com cargas de trabalho mais exigentes, a arquitetura lakebase estende ainda mais essa base.

É importante avaliar esses trade-offs com cuidado. A previsibilidade de desempenho, o custo em escala e fatores como latência de cold start e gerenciamento de conexões variam de acordo com a carga de trabalho.

A escolha do provedor é crucial. Diferenças no comportamento de cold start, modelos de precificação, granularidade de escalabilidade e compatibilidade com o ecossistema podem impactar significativamente os resultados. Para cargas de trabalho de análise e engenharia de dados, plataformas como o Databricks SQL oferecem execução de consultas serverless. As equipes também podem explorar como esse modelo se estende a cargas de trabalho operacionais por meio do tour do produto Databricks Lakebase.

À medida que as arquiteturas de banco de dados continuam a evoluir, a arquitetura lakebase unifica cargas de trabalho operacionais e analíticas em uma base de dados compartilhada.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original