O SQLite deveria ter edições (no estilo Rust)

Conceito de edições e objetivos

• Muitos comentaristas gostam da ideia de uma pragma de “edição” ou “nível de compatibilidade” que agrupe um conjunto de padrões modernos (por exemplo, tipagem mais estrita, imposição de FKs, tempo limite de espera, WAL) sem quebrar código antigo.
• As edições são vistas como uma forma opcional de ir além de padrões com 20 anos de idade, preservando ao mesmo tempo a promessa de compatibilidade retroativa do SQLite.
• São feitas comparações com edições do Rust, “épocas/perfis” do C++, políticas do CMake, compatibility_level do Postfix e use strict do JS.

Compatibilidade retroativa e portabilidade

• O SQLite é um contêiner de dados frequentemente տեղափոխado entre máquinas e ferramentas; binários antigos de /usr/bin/sqlite3 muitas vezes leem arquivos criados por versões embutidas mais novas.
• Críticos temem que edições possam:
  • Exigir entendimento tanto das pragmas subjacentes quanto dos mapeamentos da edição.
  • Bloquear versões intermediárias do SQLite se a edição N implicar recursos adicionados depois.
  • Complicar o tratamento de dados existentes quando semânticas mais estritas forem ativadas.
• Os defensores respondem que esses são em grande parte os mesmos problemas das pragmas individuais de hoje e propõem:
  • Tornar as edições apenas macros no nível da conexão (não armazenadas no arquivo).
  • Manter regras estritas de mão única e metadados autoexplicativos.

Padrões: FKs, tipagem, busy timeout, WAL

• Muitos concordam que os padrões atuais (sem imposição de FK, tipagem flexível, sem busy timeout, rollback journal) são ruins para o uso típico de “banco de dados de app” e são rotineiramente substituídos.
• Outros defendem o status quo:
  • Ambientes embarcados/de poucos recursos podem preferir minimalismo e tipagem flexível.
  • busy_timeout é inerentemente específico da aplicação; escolher 5s versus 1s versus 60s é arbitrário.
  • WAL é um formato diferente, não universalmente suportado, e visto como mais arriscado em termos de corrupção.

Tipagem, tabelas STRICT e qualidade de dados

• Vários comentaristas acham o sistema de tipos do SQLite “perigoso” e prefeririam tipagem estrita como padrão.
• Outros argumentam que a tipagem flexível é inestimável para ingerir CSVs/dados legados bagunçados, em que datas, números etc. inválidos são comuns.
• As tabelas STRICT são vistas como um passo útil, mas não como uma solução completa de validação; validação séria muitas vezes ainda pertence a uma camada superior.

Escopo do SQLite e alternativas

• Há forte rejeição a transformar o SQLite em um sistema cliente-servidor, altamente concorrente; alguns dizem “use Postgres” ou outros motores embarcados (DuckDB, Firebird) se você precisa disso.
• Contraponto: mesmo um banco de dados local de aplicativo deveria ter padrões mais seguros; edições ou conjuntos de recursos poderiam fornecer isso sem alterar o comportamento legado.

Preocupações de implementação e ecossistema

• As preocupações incluem inchaço de código para cada edição adicionada, crescimento da superfície de testes e possível confusão (“edição 2026” esconde o que realmente está habilitado).
• Mitigações sugeridas: implementar edições como pequenas macros sobre pragmas existentes; possivelmente permitir apenas um conjunto limitado, ou conjuntos de recursos em vez de edições baseadas em ano.
• Alguns ecossistemas de ORM e wrappers ficam para trás em recursos mais novos do SQLite (por exemplo, STRICT), reduzindo o benefício prático até que as ferramentas acompanhem.