Executável é um Banco de Dados SQLite

Artigo original ↗ Discussão no Hacker News ↗

Transformar um executável em um formato de banco de dados SQLite desperta tanto admiração pela criatividade quanto ceticismo quanto à sua praticidade. Comentadores destacam que essa abordagem poderia unificar ferramentas, tornar binários consultáveis com SQL e até servir como contêiner para código, dados e plugins, mas enfatizam trade-offs sérios, como a perda de compartilhamento baseado em `mmap`, maior uso de memória e complexidade ao adaptar o layout de armazenamento do SQLite. A conversa se amplia para uma ideia recorrente em design de sistemas — substituir ou apoiar sistemas de arquivos, executáveis e até serviços de SO com abstrações baseadas em banco de dados — enquanto questiona até onde essa tendência de “SQLite para tudo” deve ir.

Reações gerais

  • Muitos leitores acharam o projeto divertido, engenhoso e um “ótimo projeto de hacker”, especialmente pelo uso de bibliotecas dinâmicas e de detalhes internos de ELF.
  • Outros apreciaram a inventividade, mas não sentiram que ele resolvesse um problema urgente para usuários típicos; pareceram considerar mais claramente útil para pessoas que já manipulam binários ELF.
  • Vários compararam a ideia a conceitos existentes: imagens de Smalltalk/Lisp/Forth, contêineres no estilo zip/JAR, redbean, DBOS, AS/400/PICK e noções de sistemas operacionais do tipo “tudo é um banco de dados”.

Formato do executável e trade-offs de desempenho

  • Principal preocupação: segmentos de texto são copiados para fora das B-trees do SQLite em vez de serem mmap-ados.
    • Isso impede o compartilhamento de páginas de texto entre processos e prejudica a eficiência de memória e swap, especialmente em sistemas com muitas bibliotecas dinâmicas.
  • Alguns sugeriram:
    • Alinhar e preencher BLOBs para que se tornem regiões alinhadas a páginas e mmap-áveis.
    • Aumentar o tamanho da página do SQLite (por exemplo, 64 KB) para obter grandes áreas contíguas.
    • Escrever um VFS personalizado do SQLite para separar cabeçalhos dos dados.
    • Usar conversão SELF→ELF no momento do carregamento, para que o binário em execução seja um ELF normal.
  • Vários observaram que evitar cópias e permitir mmap é “o ponto central” dos formatos executáveis, então esse trade-off não é trivial.

SQLite como contêiner / sistema de arquivos / interface

  • Houve forte interesse em SQLite como um formato de contêiner genérico, rico em ferramentas, para executáveis, documentos, imagens e mais; em contraste com formatos binários ad hoc e ZIP+XML (OOXML/ODF).
  • Alguns argumentaram que o sistema de arquivos já é um “banco de dados” composável, com diretórios agindo como sub-bancos; o namespace plano do SQLite é menos adequado para isso.
  • Outros gostaram da ideia de um sistema de arquivos apoiado em banco de dados que ainda apresenta uma árvore hierárquica aos usuários, mas permite consultas no estilo SQL sobre metadados ricos.

Desenhos alternativos e ferramentas relacionadas

  • Vários comentaristas sugeriram manter ELF e expô-lo por meio de tabelas virtuais SQL, em vez de alterar o formato em disco.
  • Ferramentas mencionadas: osquery, nushell, Steampipe, tabelas virtuais do SQLite para montar sistemas de arquivos e trabalhos anteriores usando SQLite como contêiner embutido de aplicações.

Críticas, perguntas e ambiguidades

  • Alguns viram o projeto como o uso do SQLite como um “martelo favorito” em vez de um novo formato de objeto com princípios mais claros.
  • Um comentarista contestou a दावा do artigo de que o SQLite “interna” strings; ele relata strings duplicadas em disco e diz que a interning precisa ser feita explicitamente.
  • Outros imaginaram mecanismos mais ricos de plugins e relinking dentro do executável SQLite, mas isso continua especulativo.

Meta: títulos e cultura de pesquisa

  • O filtro de título do HN removendo “Your” gerou pedidos por um de-clickbaiting mais inteligente ou assistido por LLM, ou por reescrever “Your” → “My”.
  • A nota do autor de que o feedback acadêmico foi duro provocou discussão de que trabalhos de sistemas de baixo nível e mais “artísticos” são subvalorizados em relação a métricas puras de desempenho.