¿Se puede usar GitHub como base de datos? SQLite, peticiones HTTP Range y archivos planos

Publicado: 30 de agosto de 2026. Categoría: Arquitectura & Sistemas. Tiempo de lectura: ~4 min
Etiquetas: SQLite, GitHub Pages, HTTP Range, Arquitectura, Cloud

Siempre ando buscando formas de mantener mis proyectos personales con cero mantenimiento y cero costos de servidor, así que me puse a pensar: ¿se puede usar GitHub de pana como una base de datos persistente?

La respuesta corta es que técnicamente sí, pero con sus buenos matices. Funciona fino para conjuntos de datos estáticos de solo lectura, y bastante chimbo si necesitas escrituras concurrentes en tiempo real.

Aquí te muestro cómo implementé la jugada, cómo funciona SQLite sobre peticiones HTTP Range y las limitaciones operativas que aprendí en el camino.

1. SQLite de solo lectura con peticiones HTTP Range

Un patrón bien elegante consiste en subir un archivo .sqlite a GitHub Pages o Releases y consultarlo directamente desde el navegador sin tener que bajarte la base de datos completa.

Cliente en el navegador (sql.js-httpvfs o SQLite WASM)
Consulta: SELECT * FROM articulos WHERE id = 42;
1. Lee los primeros 100 bytes del header de SQLite
2. Pide la página raíz del B-Tree (Range: bytes=4096-8191)
3. Pide la página hoja con la fila (Range: bytes=16384-...)
                       │
                       ▼ HTTP GET con cabecera Range
GitHub Pages o CDN (archivo database.sqlite)

Cómo funciona la cosa:

Sistema de archivos virtual (VFS). Librerías como sql.js-httpvfs o el build oficial de SQLite en WebAssembly reemplazan la interfaz de disco habitual del sistema operativo (sqlite3_vfs).
Descargas selectivas por byte-ranges. En lugar de meterte 300MB a los trancazos en la memoria del navegador, el cliente envía peticiones HTTP con Range: bytes=inicio-fin.
Navegación del árbol B (B-Tree). Como SQLite organiza las tablas e índices en páginas fijas de 4096 bytes, el motor pide únicamente las 2 a 4 páginas exactas para completar la búsqueda indexada.

Ventajas:

Cero costos de infraestructura en CDNs estáticos.
Caché salvaje en el Edge sobre rangos de bytes.
Consultas volando sobre datos estáticos pesados como catálogos, censos o índices de búsqueda.

2. Lectura y escritura con commits y la API de GitHub

GitHub no corre servicios como Postgres o MySQL escuchando conexiones TCP directas. Para modificar datos, interactúas mediante la API REST de GitHub o flujos de trabajo de Git.

Archivos planos estructurados (JSON / YAML / Markdown)

No te pongas a hacer commit de archivos binarios .sqlite en cada escritura porque los packfiles de Git van a inflar el repo a lo loco. Es mil veces mejor guardar las cosas en archivos de texto plano:

data/
  ├── users/
  │    ├── usr_01.json
  │    └── usr_02.json
  └── telemetry/
       └── 2026-08-30.json

Tu aplicación envía una petición PUT /repos/{owner}/{repo}/contents/{path} con los datos en base64.
Cada escritura te deja un commit inmutable con fecha y diffs legibles al tiro.

Issues y Discussions como base de datos estructurada

Sistemas de comentarios como Giscus y Utterances guardan los comentarios en GitHub Discussions o Issues. Esto te da autenticación con GitHub, moderación, filtros de spam y notificaciones listas de fábrica sin tener que pagar un centavo de backend.

GitHub Actions para tareas batch programadas

Flujos automáticos con cron pueden correr scrapers, actualizar archivos JSON o SQLite y hacer commit del resultado de vuelta al repo sin que tengas que mover un dedo.

Comparativa

Característica	GitHub como DB	SQLite Serverless (Turso / D1)	Managed DB (Postgres / RDS)
Costo de hosting	$0 (Gratis)	Capa gratuita / Pago por lectura	$15 a $100+/mes
Latencia de lectura	50ms a 300ms (en CDN)	10ms a 30ms (Edge)	5ms a 20ms
Latencia de escritura	1s a 5s (commit en Git)	10ms a 50ms	Menor a 5ms
Concurrencia	Peligro de merge conflicts	Replicación multirregión	Bloqueos ACID por fila
Límites de API	5,000 peticiones/hora	Millones de ops/mes	Límite del connection pool
Diffs binarios	Infla la carpeta `.git`	Almacenamiento limpio	Archivos estándar WAL

Conclusiones

Usa GitHub Pages con SQLite VFS si tienes un dataset estático de solo lectura que quieras alojar gratis sin tener que mantener servidores.
Usa archivos planos con la API de GitHub para escrituras esporádicas donde quieras historial y trazabilidad, como comentarios de blogs o marcadores personales.
No inventes usar GitHub como base de datos en aplicaciones que requieran escrituras en milisegundos, alto tráfico transaccional o datos privados de clientes.

Can you use GitHub as a database? SQLite, HTTP range requests, and flat files

Published: August 30, 2026. Category: Architecture & Systems. Reading time: ~4 min
Tags: SQLite, GitHub Pages, HTTP Range, Architecture, Cloud

I often look for ways to keep side projects zero-maintenance and zero-cost, which made me wonder: can I just use GitHub as a persistent database?

The short answer is yes, but it depends heavily on read and write patterns. It works surprisingly well for read-heavy static datasets, and terribly for real-time concurrent writes.

Here is my architectural look at how SQLite over HTTP range requests works on GitHub Pages, how to handle flat-file writes, and where the operational trade-offs break down.

1. Read-only SQLite with HTTP range requests

A clean pattern is hosting a .sqlite file on GitHub Pages or Releases and querying it directly from the browser without downloading the full database.

Browser client (sql.js-httpvfs or SQLite WASM)
Query: SELECT * FROM articles WHERE id = 42;
1. Reads SQLite 100-byte header
2. Fetches B-Tree root page (Range: bytes=4096-8191)
3. Fetches target leaf page (Range: bytes=16384-...)
                       │
                       ▼ HTTP GET with Range headers
GitHub Pages or CDN storage (database.sqlite)

How it works:

Virtual File System. Libraries like sql.js-httpvfs or SQLite's official WebAssembly build replace SQLite's default OS disk interface (sqlite3_vfs).
Partial byte downloads. Instead of loading a 300MB database into memory, the browser sends HTTP requests with Range: bytes=start-end.
B-Tree navigation. SQLite organizes tables and indexes into fixed 4096-byte pages. The engine requests only the 2 to 4 pages required to complete an index lookup.

Advantages:

Zero hosting costs on static CDNs.
Edge caching on static byte ranges.
Fast lookups on large read-only datasets like public census records or search indexes.

2. Read-write patterns with Git commits and GitHub API

GitHub does not run database daemons like Postgres or MySQL listening on raw TCP sockets. To write data, you use the GitHub REST API or Git workflows.

Flat-file document storage (JSON / YAML / Markdown)

Do not commit binary .sqlite files on every write because Git packfiles will balloon in size. Instead, store entities as plain text files:

data/
  ├── users/
  │    ├── usr_01.json
  │    └── usr_02.json
  └── telemetry/
       └── 2026-08-30.json

Your app sends a PUT /repos/{owner}/{repo}/contents/{path} request with base64 data.
Every write creates a Git commit with a timestamp and clean text diffs.

Issues and discussions as structured storage

Comment engines like Giscus and Utterances map comments directly to GitHub Discussions or Issues. You get GitHub authentication, spam filtering, and notifications without building a backend.

GitHub Actions for scheduled batch jobs

Workflows triggered on a cron schedule can run scrapers, update JSON or SQLite files, and commit the updated data back to the repo.

Comparison

Feature	GitHub as a DB	Serverless SQLite (Turso / D1)	Managed DB (Postgres / RDS)
Hosting cost	$0	Free tier / Pay per read	$15 to $100+/month
Read latency	50ms to 300ms (CDN)	10ms to 30ms (Edge)	5ms to 20ms
Write latency	1s to 5s (Git commit)	10ms to 50ms	Under 5ms
Concurrency	Risk of merge conflicts	Multi-region replication	ACID row locks
Rate limits	5,000 requests/hour	Millions ops/month	Connection pool bound
Binary diffs	Large `.git` bloat	Clean storage engine	Standard WAL storage

Conclusion

Use GitHub Pages with SQLite VFS if you have a static, read-only dataset that you want to host for free with zero maintenance.
Use flat files with the GitHub API for low-frequency writes where you want an audit trail, like static blog comments or personal bookmarks.
Avoid GitHub as a database for applications that need fast write latencies, high concurrency, or private customer records.