O que são executáveis consultáveis
Executáveis consultáveis são uma proposta experimental para transformar o próprio arquivo do programa em um banco SQLite. Em vez de separar código, conteúdo e estado em vários arquivos, a ideia é guardar tudo em um único artefato que também pode receber consultas SQL.
O conceito aparece no formato SELF, apresentado por Farid Zakaria em uma publicação de 24 de agosto de 2026. A proposta usa uma tabela de segmentos para representar o programa e permite que um interpretador prepare o arquivo para execução no Linux.
O interesse está na mudança de perspectiva. Um binário deixa de ser apenas um pacote opaco e passa a ser um arquivo que você pode inspecionar com ferramentas conhecidas, como o SQLite. Ainda assim, o SELF é um experimento técnico, não um padrão pronto para substituir bancos de dados ou sistemas de empacotamento.
O SELF é uma prova de conceito. Use-o para aprender e experimentar, não como base automática para um sistema de produção.
Como funciona
O arquivo combina uma estrutura executável com uma estrutura SQLite. O programa pode carregar seus segmentos, bibliotecas e ponto de entrada a partir das tabelas do banco. Assim, o mesmo arquivo tem bytes necessários para rodar e linhas que descrevem o conteúdo.
No Linux, o mecanismo binfmt_misc permite associar um formato de arquivo a um interpretador. Quando o sistema reconhece um arquivo SELF, o interpretador lê a tabela de segmentos e encaminha a execução para o ponto de entrada adequado.
A parte mais curiosa é que o processo pode abrir o arquivo que está executando. O projeto usa o caminho recebido em argv[0] para acessar o próprio banco. Com isso, o servidor de demonstração consulta rotas, registra visitas e grava ações no mesmo arquivo que contém o programa.
Uma analogia simples é imaginar um aplicativo dentro de uma caixa que também tem fichários. O código é o mecanismo, as tabelas são os fichários e o interpretador é quem sabe abrir a caixa na ordem correta.
Principais recursos
O primeiro recurso é a inspeção por SQL. Depois de criado, o arquivo pode ser analisado com o cliente do SQLite, permitindo consultar tabelas, contar registros e verificar o estado sem uma ferramenta proprietária.
O segundo é a possibilidade de distribuir um serviço como um único arquivo. No exemplo self-httpd, o artefato reúne o programa, as páginas, as rotas e os registros de visitantes. Isso reduz a quantidade de peças que precisam acompanhar uma demonstração.
O terceiro é a persistência do estado no próprio executável. Uma ação recebida pelo servidor pode ser registrada em uma tabela SQLite, com as garantias transacionais do banco. O projeto também mostra que uma nova rota pode ser representada como uma linha em uma tabela de handlers.
- Consulta: use SQL para observar o que está dentro do arquivo.
- Distribuição: leve programa e dados no mesmo artefato.
- Estado: registre informações sem criar um diretório separado para cada componente.
Como começar: instalação ou acesso passo a passo
O caminho mais seguro é tratar o SELF como um laboratório no Linux. Você precisa de um ambiente com SQLite e de uma cópia do repositório oficial selfdb. O suporte a binfmt_misc e os detalhes de compilação podem variar conforme a distribuição e a versão do projeto.
Comece clonando o repositório e entre no diretório do exemplo de servidor. Se você estiver usando um artefato já compilado, confirme primeiro que ele é realmente um banco SQLite e não execute arquivos baixados de fontes desconhecidas.
git clone https://GitHub.com/fzakaria/selfdb.git
cd selfdb/examples/server
file server
sqlite3 server '.tables'Com um servidor de demonstração pronto, execute-o em uma porta local e faça uma consulta simples. O exemplo publicado pelo autor usa o modo WAL do SQLite para o journal e escuta na porta 8080.
./server --journal wal 8080
curl -s localhost:8080 | head -1
sqlite3 server 'SELECT count(*) FROM presses;'Não há plano pago ou serviço hospedado obrigatório no conceito. O requisito principal é um ambiente compatível com o código e uma postura de laboratório. Faça backup do arquivo antes de testar escritas, porque o programa e os dados vivem no mesmo lugar.
Exemplo prático
Imagine um servidor local com uma página que contém um botão. O arquivo chamado server serve as rotas e mantém duas tabelas de estado: visits, para acessos, e presses, para cliques no botão.
Ao iniciar o processo, uma requisição GET pode registrar uma visita. Quando o cliente envia um POST para a rota de ação, o servidor insere uma linha em presses e responde com um contador. O ponto importante é que essa alteração acontece dentro do mesmo arquivo do servidor.
curl -s -X POST -d press localhost:8080/api/press
sqlite3 server 'SELECT id, at, button FROM presses;'
sqlite3 server 'SELECT path, count(*) FROM visits GROUP BY path;'Esse fluxo é útil para entender o modelo, mas não deve ser confundido com uma recomendação de arquitetura universal. Em um projeto real, você ainda precisaria tratar permissões de escrita, concorrência, backup, atualização do artefato e recuperação após falhas.
Comparação com alternativas
O modelo tradicional separa o executável dos dados. Um serviço pode rodar a partir de uma imagem ou pacote e gravar seu estado em SQLite, PostgreSQL ou outro banco externo. Essa separação costuma facilitar backup, atualização e operação, porque cada camada tem um ciclo de vida próprio.
O redbean, citado como inspiração pelo autor, também empacota um servidor em um arquivo, mas usa um executável portátil com um arquivo ZIP autoextraível e hooks em Lua. O SELF troca essa combinação por um banco SQLite que funciona como contêiner consultável.
Uma imagem de contêiner é outra alternativa para distribuição. Ela empacota o ambiente, mas normalmente mantém o estado em volumes ou serviços externos. O SELF é mais compacto como experimento de arquivo único, enquanto as alternativas maduras oferecem mais ferramentas operacionais.
- SELF: escolha para estudar executáveis que também são bancos.
- Executável e banco separados: escolha para aplicações com operação e dados bem isolados.
- Redbean: escolha para explorar um servidor de arquivo único com ZIP e Lua.
- Contêiner: escolha quando reprodutibilidade e implantação padronizada forem prioridade.
Pontos positivos e limitações
O maior ponto positivo é a concentração. Um único arquivo pode conter o programa, conteúdo, rotas e estado. Para demos, ferramentas locais e estudos de sistemas, isso torna o experimento visual e fácil de transportar.
Outro benefício é a transparência. SQL permite perguntar o que existe no arquivo sem depender de um formato binário proprietário. A possibilidade de persistir mudanças com transações também aproxima o conceito de um banco de dados real.
A limitação principal é a maturidade. O projeto é experimental e depende de detalhes do Linux, do interpretador e do próprio formato. Também há riscos práticos em permitir que um processo escreva no arquivo que está executando, especialmente durante atualização ou execução concorrente.
Se o arquivo contém código e estado, uma falha de escrita pode afetar os dois. Mantenha cópias de recuperação e teste restauração antes de confiar no modelo.
Casos de uso reais
Para quem estuda sistemas operacionais, o SELF pode funcionar como um laboratório para observar a fronteira entre formato de arquivo, carregamento de programas e banco de dados. O ganho está em enxergar os conceitos juntos em um exemplo pequeno.
Para quem cria demonstrações técnicas, um serviço de arquivo único pode simplificar o envio de uma prova de conceito. O arquivo pode carregar a aplicação web e revelar seus próprios contadores por meio de consultas SQL.
Para ferramentas locais ou dispositivos controlados, a ideia pode inspirar um artefato que guarda configuração e histórico perto do código. Isso só faz sentido quando o ambiente de execução, as permissões e a estratégia de atualização estiverem sob controle.
Para equipes de plataforma, o projeto também pode servir como referência para discutir empacotamento. Ele ajuda a comparar o que se ganha ao juntar artefatos e o que se perde em observabilidade, segurança operacional e manutenção.
Dicas e boas práticas
Comece lendo as tabelas com o processo parado. Primeiro entenda segmentos, rotas e estado; depois teste uma escrita pequena e reversível.
Use um diretório isolado e uma conta sem privilégios desnecessários. Um arquivo que pode ser alterado durante a execução merece o mesmo cuidado de qualquer banco gravável.
Compare o arquivo antes e depois de uma ação com consultas SQL e ferramentas de hash. Assim você aprende quais tabelas mudam e separa estado esperado de corrupção.
Faça cópias versionadas do artefato e documente o comando exato usado para iniciar o interpretador. Também registre quais tabelas são dados da aplicação e quais pertencem à estrutura executável.
Evite colocar dados sensíveis no arquivo. Mesmo que o modelo seja conveniente, um executável distribuído pode ser copiado, analisado e restaurado por terceiros.
Vale a pena?
Vale a pena para desenvolvedores curiosos, pesquisadores e pessoas que querem entender como um programa pode carregar dados e estado no mesmo arquivo. O SELF é uma forma concreta de estudar SQLite, binfmt_misc, carregamento de executáveis e servidores mínimos.
Não é a escolha padrão para uma API comercial, um banco de produção ou uma aplicação que precisa de atualizações frequentes. Nesses cenários, separar código, dados, logs e configuração costuma simplificar segurança e operação.
O próximo passo é clonar o repositório oficial, abrir o exemplo self-httpd e repetir as consultas do artigo de referência. Depois, tente adicionar uma tabela pequena em um ambiente descartável e observe o efeito no arquivo, sempre mantendo uma cópia de recuperação.