Bancos de dados estão se movendo para a borda — Turso, Neon e Cloudflare D1 estão reescrevendo onde seus dados vivem

Durante a maior parte da história dos bancos de dados, a pergunta sobre onde seu banco de dados vive teve uma resposta simples: em um datacenter, provavelmente uma ou duas regiões para redundância, acessível aos seus servidores de aplicação por meio de uma rede privada rápida. O banco de dados é central. Tudo se conecta a ele. A latência entre sua aplicação e seu banco de dados é medida em saltos de rede de submilissegundos dentro da mesma instalação.

O problema com esse modelo é que ele não leva em conta onde seus usuários estão. Se seus servidores de aplicação estão em us-east-1 e um usuário em Cingapura faz uma requisição, essa requisição viaja de Cingapura para Virgínia e volta — aproximadamente 200 milissegundos de latência de ida e volta antes mesmo de você pensar em consultas ao banco de dados. Plataformas Serverless modernas e Edge Runtimes aproximaram o código da aplicação dos usuários: Cloudflare Workers é executado em mais de 300 locais, Vercel Edge Functions são implantadas em dezenas de regiões. Mas a maioria das aplicações ainda consulta uma única instância Postgres ou MySQL sentada em uma região, eliminando o benefício de latência da execução no Edge no momento em que uma chamada de banco de dados é feita.

Bancos de dados de borda tentam resolver isso movendo os dados em si — ou pelo menos os dados acessados com frequência — para mais perto dos usuários.

Os principais concorrentes

Turso é construído sobre libSQL, um Fork do SQLite com Replication adicionada. A arquitetura é direta: um banco de dados primário armazena a cópia autoritativa dos seus dados, e Turso replica automaticamente para locais de borda próximos aos seus usuários. Consultas de leitura atingem a Replica mais próxima; escritas vão para a primária. Turso implantou réplicas de borda em dezenas de regiões e faz tudo parecer uma conexão SQLite padrão da perspectiva do desenvolvedor. O modelo de preço é agressivo — um generoso plano gratuito, depois precificação por banco de dados. Para aplicações com muitos inquilinos isolados (produtos SaaS onde cada cliente tem seu próprio banco de dados), o modelo do Turso é convincente: você pode ter milhares de bancos de dados por muito pouco dinheiro, cada um colocalizado perto de seu usuário principal.

Neon adota uma abordagem diferente: é Postgres Serverless, com armazenamento e computação separados. A computação escala para zero quando não está em uso (eliminando custos ociosos) e escala em segundos quando o tráfego chega. A camada de armazenamento é durável, multi-inquilino e replicada globalmente no nível de bloco. Réplicas de leitura podem ser implantadas em qualquer região. A experiência do desenvolvedor é muito próxima do Postgres padrão — strings de conexão, psql, todas as ferramentas usuais funcionam — o que reduz significativamente o atrito de migração. O recurso de Branching do Neon, que cria snapshots instantâneos Copy-on-Write do seu banco de dados para desenvolvimento ou teste, tem sido amplamente elogiado.

Cloudflare D1 também é baseado em SQLite e profundamente integrado com Cloudflare Workers. A proposta é simples: seu script Worker é executado na borda, e D1 está bem ali com ele. Para consultas que não exigem consistência global, D1 elimina completamente a viagem de ida e volta para um banco de dados central. D1 atualmente é limitado em recursos comparado a um Postgres completo — sem suporte a chave estrangeira pronta para uso, limitado ao sistema de tipos do SQLite — mas é genuinamente rápido para leituras quando colocalizado com o Worker de borda que está tratando a requisição.

PlanetScale merece uma menção por uma razão diferente: anunciou em 2024 que estava encerrando seu plano gratuito e reorientando para clientes empresariais. Vários desenvolvedores que haviam construído projetos no serviço compatível com MySQL da PlanetScale correram para migrar, e muitos acabaram no Neon ou Turso. A arquitetura baseada em Vitess da PlanetScale oferecia escalabilidade horizontal a um preço que se mostrou insustentável. O episódio foi um lembrete útil de que serviços de banco de dados gratuitos não são uma base garantida.

O problema da consistência

Bancos de dados de borda fazem uma compensação real: distribuir dados para leituras de baixa latência torna a consistência forte mais difícil de garantir. Esse não é um problema novo — o teorema CAP tem sido um pilar do ensino de sistemas distribuídos por duas décadas — mas se torna concreto nos designs de bancos de dados de borda de maneiras que vale a pena entender.

Com as réplicas de borda do Turso, uma escrita confirmada na primária pode levar algumas centenas de milissegundos para se propagar para todas as réplicas de borda. Se um usuário escreve dados e os lê imediatamente, e a leitura atinge uma réplica que ainda não recebeu a escrita, ele vê dados desatualizados. Para muitas aplicações — um blog, um catálogo de produtos, um feed social — isso é aceitável. Para aplicações onde a consistência é crítica — uma transação financeira, uma atualização de estoque com restrições rígidas — não é.

Neon lida com isso de forma diferente. Suas réplicas de leitura podem ser configuradas como síncronas (consistentes garantidas) ou assíncronas (menor latência, potencialmente desatualizadas). A maioria das aplicações pode usar réplicas assíncronas para caminhos com muita leitura e rotear escritas e leituras sensíveis à latência para a primária. A arquitetura é mais flexível que a do Turso, mas requer um pensamento mais explícito sobre quais consultas precisam de qual nível de consistência.

O modelo de consistência do Cloudflare D1 é limitado a uma única região: escritas no D1 são imediatamente visíveis para leituras na mesma região, mas a consistência global não é garantida. Os Durable Objects do Cloudflare fornecem uma primitiva diferente para estado globalmente consistente, mas Durable Objects não são um banco de dados relacional.

A convergência para SQLite

Um padrão marcante no cenário de bancos de dados de borda é quantos desses produtos convergem para SQLite como seu mecanismo de armazenamento subjacente. libSQL do Turso, Cloudflare D1, o banco de dados embutido do Bun, e vários outros usam SQLite ou um derivado. As razões são práticas: SQLite é extremamente rápido para cargas de trabalho de escritor único, é incorporado no processo da aplicação (sem servidor separado), e é extraordinariamente bem testado. O desafio sempre foi a Replication, que o SQLite padrão não suporta — libSQL, LiteFS e projetos similares estão trabalhando para preencher essa lacuna.

O surgimento do SQLite como um mecanismo de banco de dados de produção sério — além de seu papel tradicional como armazenamento local embutido — é uma das tendências de infraestrutura mais interessantes dos últimos anos. Ele roda em tudo, desde dispositivos IoT até funções Serverless Edge, e sua simplicidade é cada vez mais uma característica em vez de uma limitação.

Quando usar

Bancos de dados de borda são adequados para aplicações onde os usuários estão distribuídos globalmente, cargas de trabalho com muita leitura são a norma, e a consistência eventual é aceitável para a maioria das consultas. Produtos SaaS com bancos de dados por inquilino, plataformas de conteúdo com audiências globais e backends de API que atendem aplicativos móveis em muitas geografias são todos candidatos razoáveis.

Eles são menos adequados para aplicações com transações complexas, requisitos estritos de consistência entre muitos usuários, ou cargas de trabalho analíticas pesadas. Um livro-razão financeiro, um sistema de inventário de comércio eletrônico sob altas escritas concorrentes, ou um data warehouse provavelmente devem permanecer em um banco de dados centralizado convencional — pelo menos até que o ecossistema de bancos de dados de borda amadureça mais.

A pressão subjacente que impulsiona essa mudança não está indo embora: os usuários esperam aplicações rápidas, e aplicações rápidas precisam de dados perto dos usuários. A categoria de bancos de dados de borda ainda é jovem, as ferramentas são menos maduras que Postgres centralizado, e algumas arestas ásperas permanecem. Mas para a carga de trabalho certa, a melhoria de latência é tangível e real — e é assim que a adoção de infraestrutura geralmente começa.