Todos los artículos y comentarios de Hacker News de 2006 a 2025 respaldados en un SQLite de 22 GB

• Hacker Book es un proyecto que preserva todos los datos de Hacker News en formato SQLite desde 2006 hasta 2025
• Está compuesto por un total de 46,399,072 publicaciones y 1,637 shards, e incluye 19 años de historial de HN
• No usa una app del lado del servidor, sino SQLite compilado a WASM, y muestra la información descargando solo algunos shards cuando hace falta
• A través de la interfaz web se pueden explorar publicaciones, usuarios y comentarios, y ofrece una UI similar a la estructura en tiempo real de HN
• Entre las publicaciones destacadas hay temas variados como IA, código abierto, historia de la tecnología y asuntos sociales
• Es un recurso que brinda a desarrolladores e investigadores una base para el análisis de datos a largo plazo de comunidades tecnológicas en internet

---

Resumen de Hacker Book

• Hacker Book es un proyecto que ofrece todos los datos de Hacker News en una base de datos SQLite
  • Los datos cubren el periodo del 9 de octubre de 2006 al 28 de diciembre de 2025
  • Está compuesto por un total de 46,399,072 elementos (items), 1,637 shards y un tamaño de 8.5 GB (según la información al pie de la página)
• El sitio web está disponible en https://hackerbook.dosaygo.com/
  • La interfaz tiene una forma similar a Hacker News y muestra lista de publicaciones, puntos, cantidad de comentarios e información del autor

Estructura de los datos y funciones de exploración

• Cada elemento está compuesto por título de la publicación, dominio de origen, puntos, autor, cantidad de comentarios y hora de publicación
• Se puede navegar mediante la página por usuario (view=user&id=) y la página de detalle por publicación (view=item&id=)
• Mediante el enlace ‘More’ se pueden cargar elementos adicionales por página

Detalles técnicos

• Los datos se ofrecen en formato SQLite, por lo que es posible hacer consultas y análisis en un entorno local
• Todo el historial de HN se integra en una sola base de datos, lo que permite a investigadores o desarrolladores realizar análisis de tendencias por periodos de tiempo
• La estructura de fragmentación de datos (sharding) ayuda a gestionar de forma eficiente grandes volúmenes de información

Importancia del proyecto

• Funciona como un archivo digital que preserva 19 años de conocimiento acumulado de la comunidad de Hacker News
• Mejora la accesibilidad de los datos abiertos, con posibles usos en investigación sobre historia de la tecnología o análisis de comunidades
• Como dice el eslogan “All the HN Belong to You”, hace público el historial completo de la comunidad para que cualquiera pueda explorarlo

[GN⁺]

Opiniones de Hacker News

• El punto clave de este proyecto es que todo corre dentro del navegador, no en el servidor
  Usa SQLite compilado a WASM, y en vez de descargar la DB completa de 22GB, trae solo los datos por shard necesarios para la página
  En el panel de red se puede ver que se cargan secuencialmente archivos como shard_1636.sqlite.gz, shard_1635.sqlite.gz
  Hace recordar al antiguo truco HTTPVFS de SQLite.js, pero esta vez usa archivos shard en lugar de range headers
  En la interfaz interactiva de consultas SQL puedes elegir directamente sobre qué shard ejecutar la consulta (1636 en total)

  • Este tipo de VFS de solo lectura se puede implementar de forma muy simple si tienes la API adecuada
    Un ejemplo de VFS que hice está aquí
    Para un ejemplo usando range requests, revisa este enlace
    Para soportar una DB SQLite comprimida con Zstandard, solo hace falta agregar esta librería

  • Me pregunto si existen más casos de una implementación real, a nivel producción, de esta idea basada en HTTP range. Parece tener mucho potencial

  • El soporte de VFS es realmente impresionante

• Estaría bueno poder integrarlo con Kiwix
  Últimamente uso un teléfono solo offline, así que veo Wikipedia, Wiktionary y el sitio de 100rabbits completamente sin conexión

• Me da curiosidad cuánto más se podría reducir con compresión
  Comentarios como “odio este sitio web porque secuestra la barra de desplazamiento” probablemente se podrían codificar con unos pocos bits

  • No sonaría raro hacer algo como el diccionario hardcodeado de Brotli (enlace relacionado)
  • Si quitamos todos mis comentarios, con 5 bits alcanzaría

• Probé select * from items limit 10, pero no devuelve resultados porque va recorriendo los shards uno por uno
  Llegó hasta 60 shards y luego se detuvo. Si especificas un solo shard, el resultado sale al instante
  DuckDB probablemente sería más rápido porque puede leer por HTTP solo las partes necesarias de un archivo parquet
  El error en las tablas users y user_domains se resuelve cambiando el filtro de shard al shard de estadísticas de usuario

  • Qué raro. Si fuera VFS, no debería comportarse así. Quizá no sea VFS

• Igual que existe la Single-page application (SPA), quizá podría surgir el concepto de Single-table application (STA)
  Si divides una tabla en shards por varias claves y la sirves como archivos estáticos, cualquier dato público podría distribuirse igual que HTML estático

  • El patrón de arquitectura Baked Data es parecido a esto
  • ¿Querías decir “single database” en vez de “single table”? Es difícil crear apps sin relaciones, aunque Reddit operaba con una enorme tabla única llamada “things”

• El repositorio ahora devuelve 404
  Quería ver al menos parte de los datos para entender la estructura interna, qué lástima

  • Lo bajaron rapidísimo. He estado buscando datasets recientes de HN y casi no se consiguen

• A mí también me sale error 404
  Me pregunto si consideraron los trade-offs entre un store columnar como DuckDB y SQLite

  • Quizá MS bajó el repositorio, los otros repositorios siguen funcionando
  • Yo simplemente me fui directo por SQLite. No sé mucho sobre DuckDB
  • DuckDB probablemente comprima mejor, pero considerando la universalidad de SQLite, es una elección estándar más que suficiente
  • SQLite es útil para archivado porque permite manejar toda la DB en un solo archivo

• Esto me hizo notar otra vez que el texto es muchísimo más eficiente que el video
  Ni me imagino cuánto ocuparía meter la misma cantidad de conocimiento en video

  • YouTube mete como 100 palabras útiles en un video de 20 minutos y se la pasa buscando clics. La ineficiencia es enorme
  • Un video 1080p60 va a 5Mbps, lo que equivale a 120 mil palabras por segundo. Con una velocidad promedio de habla de 150wpm, el texto es 50 mil veces más eficiente
    Si conviertes 22GB de texto a video, da alrededor de 1PB (1000TB)
  • Hoy en día también se pueden generar automáticamente videos o diagramas a partir de texto con video LLM
    Para videos de juegos de mesa o programación, es mejor resumirlos en texto y leerlo

• Estaría bueno convertir esto en un archivo .zim para verlo en un navegador offline como Kiwix
  A veces hago un “día solo offline” para organizar lo que aprendí, y uso Kiwix para consultar Wikipedia o StackOverflow
  Presentación de la biblioteca de Kiwix

  • Sería genial poder explorar este tipo de contenido directamente desde la app de Kiwix

• Yo también hice algo parecido
  Hice en Rust una herramienta para importar a SQLite el dump de Project Arctic Shift de Reddit
  Si importas sin índice FTS5, sin WAL y con --unsafe-mode, puedes importar todos los comentarios y publicaciones en unas 24 horas, y se genera una DB de unos 10TB
  Las funciones JSON de SQLite están muy buenas, pero yo opté por parsear una sola vez durante la carga y luego normalizar
  La construcción de la DB es rápida, pero si ejecutas VACUUM enseguida, la velocidad de consulta mejora mucho. Eso sí, VACUUM tarda días
  Pushshift Importer / enlace al dump de Arctic Shift

  • Si usas auto_vacuum de SQLite, puedes recuperar espacio sin reconstruir toda la DB