Limbo - uma reescrita completa do SQLite em Rust

• Limbo é um projeto experimental que reimplementa o SQLite em Rust para oferecer segurança de memória
  • Gostaram da natureza embarcada do SQLite, mas queriam um modelo de desenvolvimento mais aberto, o que levou ao início do projeto libSQL
• Motivo para fazer um fork do SQLite: facilita a integração de novos recursos e permite manter compatibilidade com o código existente
  • Desvantagem: a suíte de testes do SQLite é proprietária e escrita em C, o que dificulta a evolução do código
• Nova abordagem
  • Ao adicionar recursos de busca vetorial, encontraram os limites do SQLite
  • Reescrever o SQLite do zero para manter compatibilidade e, ao mesmo tempo, explorar a possibilidade de adicionar recursos de forma mais agressiva
• Próximos passos
  • Transformar o Limbo em um projeto oficial da Turso
  • Objetivo de construir uma nova arquitetura que ofereça segurança de memória mantendo a mesma confiabilidade do SQLite
• Desafiando a confiabilidade do SQLite
  • Alta confiabilidade garantida por meio de testes de simulação determinística (DST)
  • Em parceria com a Antithesis, uso de um framework de DST em nível de sistema
• Estado atual
  • I/O totalmente assíncrono: o Limbo tem um design totalmente assíncrono, resolvendo os problemas da interface síncrona do SQLite
  • Projetado para WASM: design pensado para uso em ambientes WASM
  • Desempenho: em muitas tarefas, desempenho equivalente ou superior ao do SQLite
  • Simplicidade: oferece uma experiência melhor ao remover recursos menos importantes em ambientes modernos
• Informações adicionais
  • O Limbo está disponível no GitHub sob licença MIT
  • Convida pessoas interessadas em construir bancos de dados embarcados que queiram levar a proposta do SQLite ao próximo nível

[seonwoo960000]

É curioso ver um projeto para o qual eu contribuía aparecer no Hacker News haha

[GN⁺]

Comentários no Hacker News

• O SQLite parece ser um projeto que não precisa ser reescrito, devido à qualidade do código e aos testes rigorosos

  • Há quem ache que seria melhor reescrever outro código em C primeiro

• A discussão de que o SQLite não é "aberto a contribuições" ignora que aceitar contribuições não significa sempre incorporá-las

  • O SQLite tem um processo para contribuições e funciona implementando recursos propostos
  • Outros projetos do ecossistema SQLite, como Litestream e LiteFS, também têm políticas de contribuição semelhantes

• Houve uma reação negativa ao anúncio inicial do fork de SQLite3 para LibSQL

  • Como a suíte de testes do SQLite3 é proprietária, achava-se que o fork provavelmente fracassaria
  • Mas, se houver um grande diferencial de produto, como uma reescrita em uma linguagem com segurança de memória, então o fork faz sentido

• Para desempenho máximo, deve-se escolher o modo WAL e desativar os bloqueios consultivos POSIX

  • Há quem se pergunte se o modo wal2 está no radar do projeto

• Há comentários de pessoas dizendo que foi a primeira vez que souberam que a suíte de testes do SQLite é proprietária

  • O Android foi construído de forma parecida, mas isso é outra questão

• Não concordam com a lógica da seção sobre "async IO"

  • Não consideram necessário reescrever o SQLite para adicionar uma interface assíncrona
  • O problema da interface síncrona do SQLite é que a thread fica ociosa enquanto espera pelo IO
  • O SQLite foi projetado para rodar muito próximo do armazenamento, então o bloqueio de IO pode ser muito curto ou inexistente

• Há opiniões de que é um projeto em estágio inicial

  • Foi fornecido um exemplo de código usando Python e Limbo

• Compilando com Fil-C, é possível obter um SQLite com segurança de memória

  • São necessárias apenas pequenas mudanças, e ele quase passa na suíte de testes

• O SQLite é composto por cerca de 156.000 linhas de código e 92.000 linhas de código de teste

• Presume-se que a certificação DO-178B para a variante em Rust não esteja sendo considerada

• O nome "Limbo" também foi usado na linguagem pós-C/UNIX do sistema operacional Inferno, da AT&T

[aer0700]

O SQLite parece ser um projeto que não precisa ser reescrito por causa da qualidade do código e dos testes rigorosos -> essa avaliação do sqlite é realmente invejável e incrível.

[regentag]

Dizem que segue o processo DO-178B e alcançou 100% de cobertura de código MC/DC.
A história desconhecida do SQLite