Fatos curiosos sobre o SQLite

• O SQLite é o banco de dados mais distribuído e mais usado

  • Há mais de 1 trilhão de bancos de dados SQLite em uso, e ele é mantido por três pessoas
  • Não aceita contribuições externas

• O SQLite é mais usado do que todos os outros motores de banco de dados somados

  • Existem bilhões de cópias do SQLite, e ele está em toda parte

• O SQLite é um dos módulos de software mais distribuídos do mundo

• A Hwaci é a empresa que desenvolveu o SQLite e também se interessa por música

• O SQLite começou em um navio de guerra dos Estados Unidos

  • D. Richard Hipp (DRH) estava desenvolvendo software para um destróier da Marinha chamado USS Oscar Austin
  • Sempre que o servidor caía, o software existente parava de funcionar
  • DRH idealizou um banco de dados que funcionasse sem servidor

• O SQLite não é open source no sentido jurídico

  • Open source exige uma definição específica e uma licença aprovada pela OSI
  • Em vez disso, o SQLite está em domínio público, com menos restrições do que uma licença open source

• Não aceita contribuições externas

  • Só pessoas convidadas podem contribuir, e as contribuições devem ser dedicadas ao domínio público

• O código de testes do SQLite

  • Para cada linha de código do SQLite, existem mais de 600 linhas de código de teste
  • Os testes cobrem 100% de todos os ramos da biblioteca

• Alguns testes do SQLite são proprietários

  • O conjunto de testes chamado TH3 é proprietário, e para acessá-lo é preciso entrar para o consórcio SQLite

• O modelo de negócios do SQLite

  • Gera receita com suporte pago, serviços de manutenção, associação ao consórcio e extensões comerciais

• O SQLite tem um código de ética em vez de um código de conduta

• O SQLite é muito rápido e, em alguns casos de uso, é 35% mais rápido que o sistema de arquivos

• O SQLite adota um modelo de escritor único

  • Não permite vários escritores ao mesmo tempo

• Diferenças em relação a outros bancos de dados

  • Por padrão, usa o modo de rollback journal, e chaves estrangeiras vêm desativadas
  • Usa tipagem fraca, e tipagem forte é opcional

• É incômodo que o SQLite não tenha tipos rígidos

  • É possível inserir dados sem restrições de tipo

• O SQLite dá enorme importância à compatibilidade

  • Todas as versões do SQLite 3 conseguem ler e escrever arquivos de banco de dados das versões iniciais

• O autor do SQLite, DRH, concluiu que os sistemas tradicionais de controle de versão não eram adequados e por isso desenvolveu o Fossil

• DRH programou uma B-Tree em um avião com base nos algoritmos do livro TAOCP

• A pronúncia recomendada de SQLite é "Ess-Cue-El-Lite", mas não há orientação oficial

[dalinaum]

O SQLite não é um banco de dados tão rápido quanto se imagina. O MongoDB Realm, hoje descontinuado, é bem mais rápido. Parece que, para as pessoas, velocidade não era um fator de escolha tão importante assim.

[dalinaum]

Houve alguém que perguntou por que o Realm era rápido e pediu evidências, mas parece que a MongoDB removeu o texto ao descontinuar o suporte.

Então, com base no que lembro da época em que trabalhei nisso, vou explicar os motivos técnicos. Acho que a principal vantagem era que o Realm usava menos memória que o SQLite e tinha uma taxa de acerto de cache maior.

O Realm basicamente escolhe quanto armazenar em memória com base no tamanho realmente usado. Por isso, mesmo que o usuário escolha tipos de dados de tamanho grande, em muitos casos a serialização é feita em tamanhos pequenos, de apenas alguns bits. A conversão só acontece quando o usuário realmente passa a usar dados maiores.

O Realm agrupa e armazena juntos dados do mesmo tipo, de forma contígua. Muitas vezes o usuário não acessa todos os dados de uma tabela, mas acessa em sequência apenas uma parte deles. Por causa daquela codificação de tamanho reduzido mencionada antes, a quantidade de dados que pode ser encontrada no cache de uma vez fica muito maior.

O Realm não faz hydrate em objetos POJO; em vez disso, entrega os dados quando necessário por meio de getters e setters. Para isso, no caso do Java, ele faz manipulação no nível de bytecode. O motivo de tipos de dados como Protobuf terem sido usados naquela época no app do Facebook da Meta é que esse processo de hydrate trazia uma grande desvantagem de desempenho, e acessar apenas os dados necessários era uma vantagem.

O Realm era muito mais rápido que o SQLite na maioria dos cenários, mas não acho que isso tenha sido um fator tão importante no mercado.

Pelo que lembro, o maior concorrente do Realm era o Parse, feito pelo Facebook. Depois disso, o concorrente passou a ser o Firebase, do Google. Os dois não são bancos de dados móveis locais, e sim serviços para armazenar dados remotamente de forma simples. Pode parecer estranho que esses dois fossem concorrentes do Realm, mas, na prática, o usuário só queria salvar os dados em algum lugar, e velocidade não parecia ser tão importante.

Depois, com o investimento da Ericsson, o escopo do Realm foi reduzido. A Ericsson via que o Realm já tinha certa participação no iOS, mas não entendia por que seguir desenvolvendo mais funcionalidades. Em vez disso, reconheceu mais valor nele como solução de sincronização. Depois, o Realm foi incorporado à MongoDB.

[aer0700]

Acho que 80% do motivo de eu ter escolhido o SQLite foi o fato de ele ser fácil de lidar.

[dalinaum]

Acho que este também é um dos motivos importantes. O Realm oferecia uma forma de uso baseada em thread local, fornecia atualização automática e dizia que, ao fazer uma nova consulta em outra thread, era possível repassar os mesmos dados com um custo muito baixo; recomendava, porém, não transferir dados entre threads, mas não era fácil explicar esse tipo de coisa.

[sanggi]

Parece que o SQLite é usado em lugares realmente muito diversos!

[xguru]

Histórias pouco conhecidas do SQLite

[GN⁺]

Comentários do Hacker News

• Há quem diga que a OSI não é o padrão definitivo para definir o que é open source. A definição de open source da OSI é útil, mas também recebe críticas e gera controvérsia. Afirmar que o SQLite não é legalmente open source é incorreto

  • Depender da aprovação da OSI não é desejável. A lista de licenças aprovadas pela OSI reflete apenas uma história prática e política
  • Existe controvérsia sobre se o SQLite é open source. A dedicação ao domínio público não é uma licença, então não atende à OSD, mas é ainda mais aberta

• O blog parece estar tentando gerar visualizações e engajamento reciclando pontos antigos sobre um tema popular

  • As postagens anteriores do blog carecem de profundidade técnica e costumam exagerar bastante

• O SQLite tem um Código de Ética (CoE), e não um Código de Conduta (CoC). O CoC é usado como ferramenta para controlar o comportamento de contribuidores externos, enquanto o CoE é uma declaração do comportamento que os desenvolvedores do SQLite pretendem ter com os outros

• Há confusão sobre a pronúncia de SQLite. Dizem que se pronuncia "Ess-Cue-El-Lite", mas também há quem diga "S-Q-L-ite"

• O SQLite oferece suporte opcional a tabelas estritas. É possível impor tipos com CREATE TABLE name (stuff TEXT) STRICT

• O SQLite pode ser usado não apenas como banco de dados SQL, mas também como banco de dados NoSQL. A forma de armazenar dados usando colunas JSON é útil

• Há relato de experiência em um projeto com Richard Hipp. Ele obtém uma receita estável por meio de contratos de suporte

• Em uma das versões do SQLite, muitas micro-otimizações melhoraram o desempenho em 50%

• O SQLite é usado para prototipagem rápida e despejo de logs, mas há dificuldade quando se quer múltiplos writers. Esse é um dos principais motivos para deixar de usá-lo

• O SQLite adota um modelo de escritor único. O Redis também tem um modelo single-thread

• Um dos fatos curiosos sobre o SQLite é que, quando usuários começaram a telefonar para os desenvolvedores no meio da noite, foi preciso mudar o prefixo padrão de sqlite_ para etilqs_