📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Hay una base de datos instalada en más equipos que Android, iOS y Windows juntos: SQLite. Vive en tu teléfono, en tu navegador, en el firmware de media industria del planeta. Y aun así, hace doce años que existe un ejército discreto empeñado en lo mismo con ella: convertirla en una base de datos distribuida que sobreviva a la caída de un nodo. Philip O’Toole, autor de rqlite, acaba de publicar su recuento de la historia y la parte buena es que arranca en 2014, no en 2021, cuando el tema se puso de moda. Su proyecto fue el primer sistema open source en cruzar SQLite con Raft.
De la solución de una pega a una categoría con doce proyectos
La necesidad original era humilde: un sistema con cluster necesitaba almacenamiento relacional pequeño, y la pregunta de «¿quién guarda esto?» no tenía buena respuesta. Replicar SQLite con un log de consenso la resolvió: cada escritura pasa por el líder, la mayoría la confirma, y si un nodo se cae el dato sigue vivo en los otros. O’Toole lo dejó claro: rqlite es un sistema CP, el lado desfavorecido ante una partición prefiere no escribir antes que mentirle a nadie.
Doce años después, esa esquina del diseño está llena: dqlite de Canonical, para que LXD y MicroK8s no dependan de etcd; Litestream, que renuncia al consenso y transmite el WAL de SQLite a S3 para poder restaurar; LiteFS de Fly.io; cr-sqlite, que suma CRDTs; el fork libSQL, que terminó siendo Turso y en 2026 lo compró Supabase; SQLite Cloud; y D1, la versión serverless de Cloudflare. Lo que en 2014 era «un truco que armó un tipo en un fin de semana» hoy es una categoría con empresas de riesgo detrás.
Tres esquinas, tres preguntas distintas
Lo que más rescato del análisis es el orden que le pone al desorden. Tres enfoques que parecen competir y en realidad compiten por nada:
Consenso (rqlite, dqlite): un líder, quórum para cada escritura, consistencia fuerte. La pregunta es: ¿puedo sobrevivir al desastre sin esperar a restaurar?
Streaming (Litestream): una sola máquina y respaldo continuo casi gratis. La pregunta es: ¿qué hago si la máquina muere? Es la pregunta más común, aunque a los arquitectos les duela reconocerlo.
Merge (cr-sqlite y el movimiento local-first): muchos escritores, consistencia eventual, cero líder. La pregunta es: ¿puedo editar sin conexión y reconciliar después?
La mayoría de las discusiones entre estos mundos son dos personas respondiendo preguntas distintas sin darse cuenta.
Mi opinión: casi nadie necesita el cluster
Yo administro un puñado de VPS para mis propios proyectos y la tesis de Ben Johnson, creador de Litestream, me calza perfecta: la mayoría de las aplicaciones viven en una única máquina, y por eso nadie va a regalarte clusters ni quórums. Mi respuesta siempre fue menos elegante, pero igual de efectiva: respaldos automáticos con rclone hacia un disco en la nube, corriendo por cron de madrugada, sin consenso y sin líderes. Si la máquina muere, el dato está a salvo en otra parte. Es casi la idea de Litestream sin glamour: copiar lo que cambió a un depósito confiable, todos los días.
El otro aprendizaje es el del dinero. rqlite, dqlite y Litestream siguen siendo gratis y open source. El capital se lo llevaron las plataformas que convirtieron la idea en servicio con factura: Turso acabó adquirida por Supabase, y SQLite Cloud y D1 son productos cerrados. La idea vivió ocho años en open source antes de que alguien la empaquetara y la vendiera. No es cinismo: es el ciclo normal de la infraestructura moderna. Pero es una advertencia útil para nosotros, los que autoalojamos: mientras tu pregunta sea «un SQL confiable en un servidor que yo controlo», la respuesta open source de siempre sigue siendo la mejor opción.
Para el próximo proyecto pequeño que te salga, pregunta primero qué le vas a preguntar a la base de datos. Si es «¿qué pasa si la máquina muere?», una SQLite bien respaldada le gana a un cluster mal dimensionado. En un demo no luce, pero a las tres de la mañana es la pega que responde.
Fuente: Twelve years of distributed SQLite, blog de Philip O’Toole.
Fuente de inspiración: Twelve years of distributed SQLite
