Mal-entendido sobre SQLite no servidor: mais adequado para hiperescala do que para pequena escala

• Muitos desenvolvedores acreditam que usar SQLite no servidor só faz sentido para aplicações pequenas
• Os motivos geralmente são os seguintes:
  • Baixo custo de infraestrutura: não exige um servidor de banco de dados separado (opera como um único arquivo)
  • Facilidade para desenvolvimento e testes: o mesmo arquivo de DB pode ser usado no cliente e no servidor
  • Carga mínima de administração: não há necessidade de configurações complexas nem de gerenciar daemons
  • Alta confiabilidade: o SQLite é o DB mais amplamente distribuído do mundo e oferece forte durabilidade
• Ferramentas como LiteFS, Litestream, rqlite, Dqlite, Bedrock adicionam replicação e alta disponibilidade (HA) ao SQLite, tornando-o adequado para implantações de pequena escala

Mas este texto explora o potencial do SQLite para aplicações de hiperescala, e não de pequena escala

Problemas de escalabilidade dos grandes bancos de dados tradicionais

• Aplicações grandes normalmente têm dificuldade para manter PostgreSQL ou MySQL como um único DB, por isso usam bancos de dados com sharding
• Exemplos: Cassandra, ScyllaDB, DynamoDB, Vitess (MySQL com sharding), Citus (Postgres com sharding)
• Bancos de dados com sharding oferecem as seguintes vantagens:
  • Otimização de leituras em lote (Batch Read) por meio de particionamento de dados
  • Escalabilidade horizontal
  • Alto desempenho de escrita

Mas as soluções atuais de particionamento têm as seguintes desvantagens

• Esquemas rígidos (Rigid Schemas): não suportam consultas flexíveis como MySQL ou Postgres
• Mudanças de esquema difíceis: adicionar índices ou alterar relacionamentos gera alta carga operacional
• Operações complexas entre partições: é difícil manter transações ACID, exigindo técnicas complexas como two-phase commit (2PC)
• Problemas de inconsistência de dados: é difícil aplicar restrições fortes entre partições, o que aumenta a chance de perda de consistência

O potencial de bancos de dados de hiperescala baseados em SQLite

• Cloudflare Durable Objects e Turso mostram uma forma de projetar aplicações de hiperescala com base em SQLite
• Esses sistemas oferecem os seguintes pontos fortes:
  • Escalabilidade dinâmica (Dynamic Scaling): criação de bancos de dados por entidade (Entity), reduzindo a complexidade da infraestrutura
  • Bancos de dados ilimitados e de baixo custo: em vez de forçar partições de dados como no sharding tradicional, é possível criar novas instâncias de SQLite sempre que necessário
  • Distribuição global (Global Distribution): os bancos de dados podem ser posicionados mais perto dos usuários para melhorar o desempenho
  • Replicação e durabilidade embutidas (Built-in Replication & Durability): diferente do SQLite tradicional, os dados são replicados entre múltiplas regiões para manter alta disponibilidade
• Forma de substituir o sharding usando SQLite (com Cloudflare Durable Objects & Turso)
  • No modelo tradicional de sharding, vários logs de chat são armazenados em uma única partição de banco de dados
  • Com SQLite, é possível criar um banco de dados SQLite independente para cada canal, permitindo usar esquemas com muito mais flexibilidade
  • Estrutura de exemplo
    • Sharding tradicional: tabela de logs de chat + chave de partição
    • Baseado em SQLite: um DB SQLite separado por canal (incluindo logs de chat, participantes e informações de reações)
• As vantagens dessa abordagem com SQLite são as seguintes:
  • Manutenção de transações ACID locais: é possível executar transações dentro de cada DB individual sem os problemas de operações entre partições
  • I/O de alto desempenho: como o SQLite é um banco de dados em arquivo único, o desempenho de leitura e escrita é excelente
  • Aproveitamento de extensões SQL:
    • FTS5 (Full-Text Search): melhora o desempenho de busca
    • JSON1: suporte a armazenamento e consultas de dados JSON
    • R*Tree, SpatiaLite: uso de dados espaciais
  • Suporte a migrações SQL: compatível com ferramentas de migração existentes como Prisma e Drizzle
  • Suporte a migrações de esquema lentas (Lazy):
    • a migração não precisa ser executada imediatamente; é possível usar uma abordagem em que uma migração leve é aplicada ao abrir a instância SQLite

Limitações do uso de SQLite no servidor

• Falta de soluções open source e self-hosted
• Sem suporte a consultas entre bancos de dados → para análises, é necessário um data lake separado
• Ferramentas de banco de dados limitadas (navegadores SQL, pipelines de ETL, monitoramento, backup)
  • StarbaseDB está resolvendo esse problema com base em Cloudflare Durable Objects + SQLite
• Falta de um protocolo padrão unificado
  • PostgreSQL, MySQL e Cassandra usam protocolos padronizados, mas servidores SQLite ainda não têm um protocolo de rede padronizado suficientemente estabelecido
• Falta de casos em larga escala usando SQLite em hiperescala
  • Ainda faltam estudos de caso como os de Cassandra e DynamoDB, mas isso pode mudar com o tempo

Conclusão: SQLite não é apenas um DB local simples, mas uma opção forte também para aplicações de hiperescala

• SQLite não é apenas um banco de dados para projetos pequenos, mas uma ferramenta poderosa capaz de substituir abordagens tradicionais de sharding em aplicações de hiperescala
• Com Cloudflare Durable Objects & Turso, é possível dividir o banco de dados por entidade e escalar mantendo os recursos poderosos de SQL e transações ACID
• Há grande chance de se consolidar como uma alternativa mais flexível e mais fácil de administrar do que bancos de dados tradicionais com sharding

[pcj9024]

Quem seria corajoso o bastante para usar sqlite de bom grado em uma escala hipergigante que precisa dar conta de muitas requisições...

[GN⁺]

Opiniões no Hacker News

• Um usuário está considerando substituir um banco de dados customizado por SQL

  • Sqlite3 é considerado uma opção por rodar em um único servidor
  • O banco de dados é majoritariamente voltado para leitura, o que favorece o Sqlite3
  • O banco de dados customizado é muito rápido em tarefas específicas, mas a decisão é complexa
  • Foram feitos testes de benchmark comparando Sqlite3 e Postgresql
  • Sqlite3 foi cerca de duas vezes mais rápido que Postgresql em todas as tarefas
  • O banco de dados customizado foi de 100 a 1.000 vezes mais rápido que Sqlite3 no acesso a um único registro

• Um usuário está desenvolvendo um aplicativo web local-first e acha que SQLite é adequado

  • Quer uma forma fácil de sincronizar o estado do banco de dados SQLite com um serviço em nuvem
  • Turso e SQLite Cloud parecem opções promissoras
  • Está considerando uma abordagem simples em que os usuários possam enviar dados para armazenamento S3

• Há uma discussão sobre as vantagens de SQLite-Per-Partition

  • Existem limitações em cenários que exigem tabelas globais
  • Foram compartilhadas experiências com vários projetos usando SQLite

• Em ambientes com múltiplos usuários, SQLite enfrenta dificuldades por não ter MVCC

  • Há curiosidade sobre implementações e extensões compatíveis com sqlite que adicionem MVCC

• A versão 8.0 do Ruby on Rails ampliou o suporte a SQLite

  • Substituiu componentes de cache e fila de tarefas, tornando-o adequado para aplicativos web comuns

• Um usuário que não conhece bem Vitess ou Citus tem dificuldade para entender o conteúdo do artigo

  • Pergunta qual é a diferença entre Sharded SQLite e Sharded Postgres

• Um usuário não queria hospedar um VPS, então criou uma página web usando SQLite

  • O banco de dados é baixado para o dispositivo do usuário para uso

• Um usuário que teve dificuldades para configurar um controlador Ubiquiti sugeriu o uso de SQLite

  • Acredita que usar SQLite no lugar de MongoDB poderia proporcionar uma experiência melhor

• Em 2022, a Apple operava cerca de 300.000 instâncias de Cassandra/ScyllaDB

  • A abordagem DB-per-tenant é vista como um caminho melhor

• TDLib (biblioteca de banco de dados do Telegram) usa SQLite

  • Cada instância do TDLib processa mais de 24.000 bots ativos simultaneamente