Todos os artigos e comentários do Hacker News de 2006–2025 com backup em 22 GB de SQLite

• Hacker Book é um projeto que preserva todos os dados do Hacker News em formato SQLite de 2006 a 2025
• É composto por 46.399.072 postagens, 1.637 shards e inclui 19 anos de histórico do HN
• Em vez de ser um app server-side, ele usa SQLite compilado para WASM e exibe os dados baixando apenas parte dos shards quando necessário
• Pela interface web, é possível explorar postagens, usuários e comentários, com uma UI semelhante à estrutura em tempo real do HN
• Entre as postagens mais populares, há temas diversos como IA, open source, história da tecnologia e questões sociais
• É um recurso que oferece a desenvolvedores e pesquisadores uma base para análise de dados de longo prazo de uma comunidade técnica da internet

---

Visão geral do Hacker Book

• Hacker Book é um projeto que disponibiliza todos os dados do Hacker News em um banco de dados SQLite
  • Os dados cobrem o período de 9 de outubro de 2006 a 28 de dezembro de 2025
  • No total, são 46.399.072 itens (items), 1.637 shards e 8,5 GB de tamanho (informação no rodapé da página)
• O site pode ser acessado em https://hackerbook.dosaygo.com/
  • A interface é semelhante à do Hacker News, mostrando lista de postagens, pontos, número de comentários e informações do autor

Estrutura dos dados e recursos de navegação

• Cada item é composto por título da postagem, domínio de origem, pontos, autor, número de comentários e horário de publicação
• A navegação é possível por meio da página por usuário (view=user&id=) e da página de detalhes por postagem (view=item&id=)
• Pelo link ‘More’, é possível carregar itens adicionais por página

Detalhes técnicos

• Os dados são fornecidos em formato SQLite, permitindo consultas e análises em ambiente local
• Ao integrar todo o histórico do HN em um único banco de dados, pesquisadores e desenvolvedores podem fazer análises de tendências ao longo do tempo
• A estrutura de sharding dá suporte ao gerenciamento eficiente de grandes volumes de dados

Importância do projeto

• Funciona como um arquivo digital que preserva 19 anos de conhecimento acumulado da comunidade do Hacker News
• Amplia a acessibilidade de dados abertos, podendo ser usado em pesquisa sobre história da tecnologia ou análise de comunidades
• Como diz o slogan “All the HN Belong to You”, o registro completo da comunidade é disponibilizado para que qualquer pessoa possa explorá-lo

[GN⁺]

Comentários do Hacker News

• O ponto central deste projeto é que tudo roda inteiramente no navegador, não no servidor
  Ele usa SQLite compilado para WASM e, em vez de baixar o banco inteiro de 22GB, busca apenas os dados por shard necessários para a página
  No painel de rede dá para ver arquivos como shard_1636.sqlite.gz, shard_1635.sqlite.gz sendo carregados em sequência
  Lembra o antigo truque do SQLite.js HTTPVFS, mas desta vez usa arquivos fragmentados em vez de range header
  Na interface interativa de consultas SQL, é possível escolher manualmente em qual shard executar a consulta (1636 no total)

  • Um VFS somente leitura assim pode ser implementado de forma bem simples se houver a API adequada
    Um exemplo de VFS que eu fiz está aqui
    Para um exemplo usando range request, veja este link
    Para oferecer suporte a um banco SQLite comprimido com Zstandard, basta adicionar esta biblioteca

  • Fiquei curioso se existem mais casos de implementação real dessa ideia baseada em HTTP range em nível de produção. Parece bastante promissora

  • O suporte a VFS é realmente impressionante

• Seria ótimo se isso pudesse ser integrado ao Kiwix
  Tenho usado um celular só offline ultimamente, então vejo Wikipedia, Wiktionary e o site do 100rabbits tudo offline

• Fiquei pensando quanto menor isso ficaria com mais compressão
  Comentários como “odeio este site porque ele sequestra a barra de rolagem” provavelmente dariam para codificar com poucos bits

  • Não seria estranho criar algo como o dicionário embutido do Brotli (link relacionado)
  • Se tirassem todos os meus comentários, 5 bits bastariam

• Executei select * from items limit 10, mas o resultado não voltou porque ele percorre os shards um por um
  Foi até uns 60 shards e parou. Se eu especificar só um shard, o resultado sai na hora
  O DuckDB provavelmente seria mais rápido, já que consegue ler por HTTP só as partes necessárias de arquivos parquet
  Os erros nas tabelas users e user_domains se resolvem ao trocar o filtro de shard para o shard de estatísticas de usuário

  • Estranho. Se fosse VFS, isso não deveria acontecer. Talvez nem seja VFS

• Assim como existe Single-page application (SPA), talvez possa surgir a ideia de Single-table application (STA)
  Se você fragmentar uma tabela por várias chaves e servir isso como arquivos estáticos, qualquer dado publicável poderia ser distribuído como HTML estático

  • O padrão de arquitetura Baked Data é parecido com isso
  • Você quis dizer “single database” em vez de “single table”? É difícil fazer apps sem relações, mas o Reddit operava com uma enorme tabela única chamada “things”

• O repositório sumiu com 404
  Queria pelo menos ver a estrutura interna, mesmo que fosse só parte dos dados

  • Caiu muito rápido. Estou procurando um dataset recente do HN e é quase impossível achar

• Aqui também aparece erro 404
  Fiquei curioso se ele considerou os trade-offs entre um armazenamento colunar como DuckDB e o SQLite

  • Talvez a MS tenha derrubado o repositório, os outros ainda estão normais
  • Eu simplesmente fui direto de SQLite. Não conheço muito bem DuckDB
  • O DuckDB talvez comprima melhor, mas considerando a universalidade do SQLite, ele já é uma escolha padrão suficiente
  • O SQLite é útil para arquivamento porque permite lidar com o banco em um único arquivo

• Isso me fez perceber de novo como texto é muito mais eficiente que vídeo
  Nem dá para imaginar o tamanho que ficaria a mesma quantidade de conhecimento em vídeo

  • O YouTube coloca umas 100 palavras úteis em 20 minutos de vídeo e ainda força clique. A ineficiência é enorme
  • Um vídeo 1080p60 a 5Mbps equivale a 120 mil palavras por segundo; considerando uma fala média de 150wpm, texto é 50 mil vezes mais eficiente
    Se 22GB de texto virassem vídeo, daria algo em torno de 1PB (1000TB)
  • Hoje em dia até dá para gerar automaticamente vídeo baseado em texto ou diagramas com video LLM
    Para vídeos de jogos de tabuleiro ou programação, é melhor só resumir em texto e ler

• Seria ótimo transformar isso em um arquivo .zim para usar em navegadores offline como o Kiwix
  Às vezes eu separo um “dia só offline” para organizar o que aprendi e uso o Kiwix para consultar Wikipedia e StackOverflow
  Apresentação da biblioteca do Kiwix

  • Seria realmente ótimo poder navegar esse tipo de conteúdo direto no app do Kiwix

• Eu também já fiz algo parecido
  Criei em Rust uma ferramenta para importar o dump do Project Arctic Shift do Reddit para SQLite
  Sem criar índice FTS5 e importando sem WAL com --unsafe-mode, dá para importar todos os comentários e posts em cerca de 24 horas e gerar um banco de uns 10TB
  As funções JSON do SQLite são ótimas, mas eu preferi fazer o parse uma única vez na carga e normalizar os dados
  A construção do banco é rápida, mas rodar VACUUM logo depois acelera muito as consultas. O problema é que o VACUUM leva dias
  Pushshift Importer / link para o dump do Arctic Shift

  • Usando o auto_vacuum do SQLite, dá para recuperar espaço sem reconstruir o banco inteiro