Pare de adotar Postgres por padrão: o caso de um CTO para distribuir SQLite em 2026

Seu time provavelmente está adotando Postgres por padrão para toda decisão de datastore. Tudo bem — até deixar de ser. O SQLite acaba de receber um aceno da Library of Congress como formato de preservação recomendado, e o ecossistema moderno (D1, Turso, LiteFS, Litestream) o transformou de brinquedo em ferramenta séria de produção. Se você se preocupa com latência na borda, isolamento por tenant, capacidade offline, custos previsíveis e portabilidade de dados, você deveria distribuir mais SQLite em 2026.

Por que isso é uma decisão para 2026, não nostalgia de 2010

Três coisas mudaram:

• Validação institucional. A Library of Congress lista o SQLite como um formato de preservação aceitável — porque é autocontido, bem documentado, tem especificação aberta e um ecossistema de ferramentas vibrante. Quando arquivistas querem que seus dados sobrevivam por décadas, isso deve fazê-lo pausar antes de apostar cada byte em protocolos de servidor proprietários.
• Plataformas nativas de borda. Cloudflare D1, o LiteFS da Fly.io e Turso (libSQL) tornaram o SQLite no lado do servidor prático, com replicação, failover e distribuição global. Agora você consegue colocar dados de baixa latência a 50–100 ms da maioria dos usuários sem inventar sua própria camada de sincronização.
• Offline-first está de volta. UIs com agentes e times de campo esperam que apps funcionem sem uma rede perfeita. Um banco de dados embarcado de arquivo único, com SQL completo, supera caches locais frágeis e gambiarras de sincronização — especialmente em desktops, onde empacotar o SQLite é trivial.

Isso não significa “arrancar o Postgres”. Significa: pare de forçar todo caso de uso por um gargalo caro, centralizado e multi-tenant.

Um framework para CTOs: Quando o SQLite vence o Postgres

Escolha SQLite primeiro quando você precisar de

• Desempenho de leitura na borda abaixo de 100 ms sem cache complexo. Distribuir um SQLite replicado para PoPs ou nós regionais pode reduzir p95 de 400–800 ms para 60–120 ms em features com predominância de leitura (dashboards, visualização de perfil, catálogos).
• Isolamento por tenant para milhares de clientes pequenos. Um arquivo de banco por tenant significa isolamento rígido, deleção GDPR mais simples e sharding limpo no nível do app. Sem raio de explosão cruzando tenants.
• UX offline-first em desktop ou mobile. CRUD local-first, busca full-text (FTS5) e funções JSON (JSON1) com um loop de sync simples superam retries frágeis de API.
• Simplicidade operacional para funcionalidades embarcadas: filas de jobs, configurações, snapshots de analytics, buffers de ingestão de eventos ou feature flags próximos ao servidor da aplicação.
• Portabilidade/conformidade de dados. Precisa de exportações sob demanda? Um arquivo .sqlite é inspecionável, navegável e arquivável com um único anexo — não um projeto de fim de semana em ETL.

Fique com Postgres (ou um data warehouse) quando precisar de

• Alta concorrência de gravação de muitos clientes no mesmo dataset. O SQLite é single-writer, many-reader. É fantástico com taxas modestas de escrita (com WAL), mas não para centenas de escritores concorrentes martelando o mesmo arquivo.
• Transações cross-tenant e integridade referencial em escala massiva. Se você junta rotineiramente grandes tabelas multi-tenant com constraints complexas, mantenha isso no Postgres.
• Workloads OLAP/BI e consultas analíticas pesadas sobre conjuntos amplos. Use um warehouse (Snowflake/BigQuery/Redshift/DuckDB) ou materialize agregados em outro lugar.
• Permissões complexas em nível de linha aplicadas no banco. Dá para implementar no SQLite, mas o Postgres tem primitivas maduras e testadas em batalha para isso.

Arquiteturas que funcionam na prática

1) Leituras aceleradas na borda com réplicas SQLite

Padrão: Postgres (fonte da verdade) + réplicas SQLite próximas aos usuários. Mantenha um esquema mínimo para os caminhos de leitura e envie atualizações via WAL ou streaming de snapshots.

• Como: Use Litestream para transmitir o WAL do SQLite para armazenamento compatível com S3, ou LiteFS para replicar um SQLite com único escritor entre regiões. Se a fonte da verdade é Postgres, materialize modelos de leitura em SQLite e os envie para nós de borda em uma cadência (por exemplo, a cada poucos segundos).
• Por quê: Você elimina o inferno de invalidação de cache. Seus nós de borda consultam um banco nativo, não um blob JSON. É coerente e depurável.
• Números: Já vimos latências p95 de APIs caírem de ~650 ms para ~90 ms em dashboards analíticos ao distribuir SQLite pré-agregado para a borda a cada 5–10 segundos, reduzindo a carga de leitura no DB primário em 50–70%.

2) Por tenant “um arquivo por cliente”

Padrão: Dê a cada cliente seu próprio arquivo de banco SQLite. Mantenha tenants quentes em storage mais rápido; tenants frios em discos mais baratos. Faça backup de cada arquivo de forma independente.

• Como: Nomeie bancos de forma previsível (por exemplo, tenants/acme.sqlite). Migre no deploy iterando pelos arquivos. Use um pool de conexões indexado por tenant. Transmita cada arquivo para S3 com Litestream ou snapshots periódicos com VACUUM INTO.
• Benefícios: Isolamento por construção; redação/remoção sem dor; raio de explosão de incidentes limitado a um único arquivo de tenant; restauração direta.
• Números: Armazenamento é barato. 10.000 tenants com média de 5 MB cada são ~50 GB. No S3, isso custa dezenas de dólares/mês, não milhares.

3) Cliente offline-first com sincronização

Padrão: Inclua o SQLite no seu app desktop/mobile. Grave localmente, mostre o resultado instantaneamente e sincronize com o servidor em segundo plano. Resolva conflitos de forma determinística.

• Como: Mantenha, por tabela, um updated_at e um last_server_version. Sincronize deltas por uma API compacta. Para conflitos, prefira last-writer-wins ou merges específicos do domínio. Se precisar de CRDTs, restrinja-os a poucas entidades de alto churn (notas, comentários) em vez de todo o esquema.
• Segurança: Use SQLCipher para criptografia no nível do app ou criptografia nativa de disco da plataforma (iOS Data Protection, Android com chaves do Keystore, Windows DPAPI, macOS FileVault).
• Números: Espere 30–70% menos “tempestades de retries” e tickets de suporte em regiões com rede instável quando as escritas forem locais primeiro e sincronizadas de forma oportunista.

4) Serverless nativa da borda (D1/Turso)

Padrão: Use um serviço gerenciado de SQLite desenhado para leituras globais com um caminho de escrita sensato.

• Opções: Cloudflare D1 (SQLite na borda, integração estreita com Workers), Turso (libSQL com réplicas de borda). Você troca um pouco de portabilidade por velocidade de desenvolvimento, autenticação integrada e distribuição sem dor.
• Trade-offs: Entenda as semânticas de escrita e de consistência eventual do seu provedor e, então, projete sua UX de acordo (UI otimista, reconciliação em segundo plano).

Fazendo SQLite do jeito certo: um checklist de implementação

Esquema e recursos

• Chaves primárias: Prefira INTEGER PRIMARY KEY para mapear ao rowid por desempenho. Use tabelas WITHOUT ROWID apenas com cuidado.
• Busca textual: Use FTS5 para busca; adicione tabelas de content para indexação rica e consultas tipo trigram via índices de prefixo.
• JSON: A extensão JSON1 oferece json_extract, json_set etc. Ótima para metadados flexíveis sem uma migração para cada campo.
• Integridade: Adicione constraints CHECK e chaves estrangeiras onde importa. Lembre-se de habilitar FKs via PRAGMA foreign_keys = ON; no momento da conexão.

Concorrência e confiabilidade

• Modo WAL: Sempre habilite Write-Ahead Logging: PRAGMA journal_mode = wal;. Você obtém concorrência de muitos leitores/um escritor e melhores características de fsync.
• Nível de sync: Em escritores que precisam sobreviver a perda de energia, use PRAGMA synchronous = FULL;. Para réplicas ou modelos de leitura derivados, NORMAL costuma bastar.
• Tratamento de busy: Defina busy_timeout (por exemplo, 5000 ms) e serialize os caminhos de escrita por meio de uma fila quando rodar atrás de um servidor web. Você ficará mais feliz com um único escritor explícito.
• Migrações: Mantenha uma tabela schema_version; aplique migrações SQL idempotentes. Para milhares de arquivos de tenants, rode migrações em lotes e rastreie falhas.
• Vacuum e tamanho de página: Escolha um page_size (geralmente 4096 ou 8192) e ocasionalmente rode VACUUM ou VACUUM INTO para otimizar e gerar snapshots de backup consistentes.

Backups e replicação

• Transmita o WAL para armazenamento de objetos: O Litestream envia continuamente o WAL para storage compatível com S3. A recuperação é rápida: restaure o último snapshot + replique o WAL. Pratique restaurações trimestralmente.
• Replicação entre nós: O LiteFS oferece um primário único gravável e muitas réplicas de leitura entre regiões com replicação em nível de página automática. Projete seu app para preferir réplicas locais para leitura e rotear escritas para o primário.
• Snapshots point-in-time: Use .backup ou VACUUM INTO a partir de uma conexão ativa para um snapshot consistente sem downtime.

Segurança e conformidade

• Criptografia: O SQLite não criptografa por padrão. Use SQLCipher para criptografia no nível do app ou dependa de criptografia de volume (EBS, LUKS, FileVault) mais controles de acesso em nível de processo.
• Controles de acesso: Você não pode GRANT/REVOKE dentro do SQLite. Faça a autorização no seu app. Para arquivos por tenant, ACLs no nível do SO mantêm limites nítidos.
• Portabilidade: A recomendação da Library of Congress importa para compromissos de exportação de dados. Enviar ou aceitar um .sqlite como formato de intercâmbio reduz atritos legais e de engenharia.

O que isso muda para sua conta de cloud e SLOs

• Menor egress de DB e classe de instância. Mover caminhos de leitura intensiva para réplicas SQLite reduz a carga no primário em 50–70% em dashboards típicos de SaaS. Isso costuma permitir uma instância Postgres menor e menos réplicas de leitura.
• Menos bugs de cache, menos incidentes. SQL de verdade na borda supera formatos de cache sob medida que divergem. Fazer root cause de uma query lenta no SQLite é mais fácil do que comparar dois blobs JSON.
• SLOs previsíveis em geos distantes. Um arquivo SQLite em um nó de borda em São Paulo coloca usuários da América Latina com 6–8 horas de sobreposição de fuso para suporte e abaixo de ~100 ms para leituras. Essa é uma UX que vende.

Os trade-offs que você precisa aceitar

• Um escritor por DB. Abrace isso: faça fila para as escritas; mantenha estreitos os caminhos críticos de escrita; projete a UX para atualizações otimistas quando as escritas forem roteadas a um primário remoto.
• Maturidade operacional sobe para a camada de aplicação. Sem auth/papéis aplicados pelo servidor, sua aplicação deve ser disciplinada quanto a autorização, migrações e roteamento por tenant.
• Semânticas de replicação variam. D1, Turso, LiteFS e Litestream parecem SQLite, mas se comportam diferente sob pressão de escrita e falhas. Teste failover, partições de rede e tempo de restauração como faria com qualquer banco.

Um plano de 30–60–90 dias para pilotar SQLite sem drama

Dias 1–30: Prove valor em uma feature intensiva de leitura

1. Escolha um dashboard ou visão de catálogo com p95 conhecido > 300 ms.
2. Defina um modelo de leitura mínimo (tabelas desnormalizadas + FTS) em SQLite.
3. Gere o SQLite a partir do Postgres diariamente; depois avance para atualizações incrementais a cada 10 segundos.
4. Sirva leituras do arquivo SQLite localmente; registre fallbacks para Postgres.
5. Meça p50/p95 e a queda de CPU do Postgres. Mire em 40–70% de melhoria de latência.

Dias 31–60: Leve para a borda e adicione resiliência

1. Replique o SQLite para duas regiões (por exemplo, US-East + América do Sul) usando armazenamento de objetos + CDN ou réplicas LiteFS.
2. Adicione health checks: PRAGMA integrity_check; no deploy; alarmes para atraso de réplica.
3. Automatize snapshots via Litestream. Documente um exercício de restauração de 15 minutos.
4. Controle o rollout da feature por um feature flag; compare orçamentos de erro.

Dias 61–90: Expanda para por tenant e offline

1. Migre uma coorte pequena de clientes para arquivos SQLite por tenant. Valide deleção, restauração e fluxos de suporte.
2. Prototipe um utilitário desktop offline-first (admin, importador, app de campo) suportado por SQLite. Envie um beta privado.
3. Decida: apenas borda, isolamento por tenant ou offline-first — escolha um para levar a produção no próximo trimestre.

Opções de fornecedores sem lock-in

• Cloudflare D1: Integração estreita com Workers. Ótimo para leituras distribuídas globalmente. Atenção ao roteamento de escrita e ao modelo de consistência eventual.
• Turso/libSQL: Um SQLite “server-ificado” com réplicas de borda. Ergonomia de desenvolvimento direta; fique de olho em nuances de compatibilidade vs SQLite upstream.
• Fly.io LiteFS: SQLite de verdade com replicação em nível de página e um único primário. Excelente se você quer máxima portabilidade e controle.
• Litestream: Envio de WAL para armazenamento de objetos, simples e direto, para durabilidade e PITR. Perfeito para arquivos por tenant.

Você pode misturar: D1/Turso para leituras no tempo da requisição, Litestream para backup durável e LiteFS quando precisar de réplicas de leitura totalmente sob seu controle.

O que seu time precisa desaprender

• “SQLite é para protótipos.” Ele alimenta grandes sistemas de produção (sistemas operacionais móveis, navegadores, IoT). Seu SaaS pode usá-lo com segurança — desde que você respeite o modelo de único escritor.
• “Caches precisam ser key–value.” A maioria dos caches vira bancos de dados ad hoc. Comece com um banco de verdade na borda; ele envelhece melhor.
• “Exportação de dados é um relatório.” Para promessas sérias de portabilidade, envie o formato real dos dados. Um único arquivo SQLite é ao mesmo tempo inspecionável por humanos e amigável a máquinas.

O ângulo nearshore

Se você opera uma organização de engenharia distribuída com parceiros nearshore, o SQLite reduz o acoplamento operacional. Você pode entregar a um time no Brazil um dataset e um ambiente autocontidos; eles podem construir e testar features offline, commitar artefatos determinísticos e enviar bundles de borda sem precisar de uma cópia completa do seu Postgres de produção. Menos cerimônia, mais resultado — com 6–8 horas de sobreposição de jornada para ciclos de feedback apertados.

Em resumo

O Postgres continua sendo sua espinha dorsal. Mas, em 2026, tratar o SQLite como de segunda classe significa abrir mão de velocidade, confiabilidade e economia. Adote-o deliberadamente onde ele brilha: na borda, por tenant e offline. A recomendação da Library of Congress é um chamado: formatos autocontidos vencem no longo prazo. Arquitete de acordo.

Pontos-chave

• O SQLite agora tem endosso institucional para preservação; não é um brinquedo — use onde ele se encaixa.
• Use SQLite para leituras na borda, isolamento por tenant e UX offline-first; mantenha Postgres para escritas de alta concorrência e lógica cross-tenant.
• Ferramentas modernas (D1, Turso, LiteFS, Litestream) tornam o SQLite no servidor prático, com replicação e backups.
• Espere melhorias de 40–70% em latência em features de leitura e 50–70% menos carga no seu DB primário.
• Projete para um único escritor: modo WAL, filas de escrita e fallbacks claros.
• Segurança requer criptografia no app ou no volume e autorização na sua camada de serviço.
• Pilote em 90 dias: comece com um modelo de leitura, leve para a borda e depois estenda para por tenant ou offline-first.