Substituto do SQLite, conheça o Limbo!

Alguns pontos.

O Limbo é um experimento e não um produto. Tem potencial de se tornar um produto e se isso acontecer entrará no lugar do libSQL que é um fork do SQLite onde eles queriam uma postura diferente já que o SQLite é open source, até mais, é de domínio público, mas não é open project.

Turso é a plataforma que eles ganham dinheiro usado o SQLite conseguindo inclusive grande escala e resiliência (não usei para dizer o quanto ele é bom, mas parece não ser ruim). Este é um dos produtos que tem pronto que eu falei em postagem anterior (não esqueça de ler o comentário que eu repliquei é é muito bom e dá mais contexto ao que eu falei). Com libSQL já dá para fazer isso não não é tão simples e talvez não tão completo o que eles oferecem, além de não ter suporte e ter os seus custos. Não avalei muito mas foi o que eu entendi sobre o Turso.

A grande vantagem do Limbo é mexer ainda mais no software abrindo mão de compatibilidade de código com o SQLite. Vi que eles conseguiram em um teste básicos mais performance, mas posso quase garantir que é porque este novo projeto tem uma engenharia melhor ou porque não usa uma base de código de C antigo para poder compilar em muitos lugares.

Ele vai permitir algumas coisas mais, como uso nativo de WebAssembly.

O desafio deles é ter o mesmo nível de testes que o SQLite tem, já que o famoso conjunto de testes do SQLite é proprietário.

Limbo nunca terá 100% das features do SQLite, isto se torna impossível quando optaram por Rust, fora que já deu para ver que eles abrem mão de algumas coisas propositalmente. Não estou dizendo que haverá alguma incompatibilidade, não temos como saber isso, mas não vai rodar em alguns lugares que o SQLite roda, talvez ele seja mais pesado ou tenha outras questões que o tornam diferente, melhor em alguns pontos, pior em outros.

Toda essa iniciativa, como outras, ajuda a usar o SQLite em mais cenários além dos muitos que ele já pode ser usado... em produção, portanto ela é muito bemvinda, e o tempo dirá o tamanho do sucesso que ele terá.

Eu gostaria até que eles fizem um fork do Limbo e manter ambos. Nesse fork poderiam abrir mão da compatibilidade com SQLite e ir além em alguns pontos. Seria bem legal, mas não vai rolar, eles colocassem muitas flags para poder compilar as features que desejar, mais do que o SQLite já faz e que no libSQL e Limbo acho que se torna mais importante. E por último eu adoraria que fizessem um engine de storage bem melhor que a do SQLite e dar uma performance muito melhor, que já é dos pontos altos dele (sim, eu sei que dá para fazer ele ser muito mais rápido, o storage atual do SQLite usa técnicas antigas, mesmo assim é mais rápido que os grandes players em grande parte das situações por ser mais simples, essas soluções já existem em outros produtos).

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

desde que conheci o projeto pockebase (alternativa ao firebase, self hosted, usando sqlite e go)
acabei me apaixonando pelo sqlite kkkk
sqlite é simples e direto ao ponto. sem burocracia.

pena que a ideia central dele não encaixa bem com replicação e multi instâncias sincronizadas.
as alternativas que fazem isso com sqlite ou são meio gambiarra ou são proprietárias.

atualmente uso o pockebase pra alguns projetos meus e em produção no meu SaaS. me atende bem mesmo sendo sqlite online

é impressão minha ou existem um onda de Rusteiros. aparece o Rust e derrepentr c c++ virou lixo e a maior inovação do momento é reescrever todo c++ em Rust por tem segurança de memória.

No lugar do SQLite gosto muito de usar o H2, tenho uma performance muito grande com ele

Adorei conhecer essa solução. Meus parabéns pelo artigo.