La evolución de SQLite distribuido: de rqlite a los servicios en la nube gestionados

En septiembre de 2014, Philip O'Toole lanzó rqlite, un sistema de código abierto que combinaba SQLite con el protocolo de consenso Raft para crear una base de datos clúster tolerante a fallos. Doce años después, O'Toole reflexiona sobre cómo este experimento inicial impulsó una categoría más amplia de soluciones de SQLite distribuido, que abarca desde CRDTs locales hasta servicios gestionados respaldados por capital riesgo.

Qué ocurrió

O'Toole construyó originalmente rqlite para resolver un problema específico de infraestructura en jut.io: proporcionar almacenamiento relacional para un sistema clúster sin designar un nodo único como poseedor permanente de los datos. Al colocar un log de Raft delante de SQLite, garantizó que cada escritura se replicara en todo el clúster, evitando la pérdida de datos si un nodo fallaba. El código fuente se publicó en GitHub ese mismo fin de semana, marcando lo que O'Toole considera la primera combinación de código abierto entre Raft y SQLite. Durante varios años, rqlite fue el único proyecto destacado en este nicho, sin otros grandes intentos de arquitecturas similares.

El panorama comenzó a cambiar en 2016 cuando Expensify lanzó Bedrock, un sistema de replicación de SQLite basado en Paxos que habían utilizado internamente durante años. Casi al mismo tiempo, apareció ActorDB, ofreciendo bases de datos SQLite replicadas con Raft para actores individuales en un entorno Erlang. Aunque ninguno logró una adopción generalizada fuera de sus empresas de origen, demostraron que el concepto de replicar SQLite estaba ganando tracción. Sin embargo, rqlite mantuvo su distinción como una herramienta independiente y de propósito general que cualquier desarrollador podía desplegar sin depender de un framework de aplicación específico.

Para 2017, Canonical desarrolló dqlite para proporcionar un almacén replicado incrustado para LXD y MicroK8s, evitando la sobrecarga operativa de ejecutar etcd. Aunque O'Toole y Mark Shuttleworth discutieron posibles colaboraciones, los proyectos divergieron en sus modelos de empaquetado. Dqlite se convirtió en una librería C incrustada directamente en las aplicaciones, mientras que rqlite permaneció como un proceso de servidor separado. Esta distinción definió sus respectivos casos de uso: dqlite para funcionalidad de base de datos dentro de productos, y rqlite para infraestructura de base de datos junto a ellos.

Cómo funciona

El mecanismo central de rqlite depende del algoritmo de consenso Raft para gestionar el estado en múltiples nodos. En este sistema CP (Consistencia y Tolerancia a Particiones), todas las operaciones de escritura deben dirigirse al nodo líder. El líder añade entonces el cambio a su log y lo replica a los nodos seguidores. Una escritura solo se considera exitosa una vez que la mayoría del clúster la confirma. Si una partición de red aísla a una minoría de nodos, estos rechazan las escrituras para evitar la divergencia de datos, asegurando una fuerte consistencia a costa de la disponibilidad durante las particiones.

Este diseño contrasta fuertemente con enfoques posteriores como Litestream, lanzado por Ben Johnson en 2021. Litestream no utiliza protocolos de consenso. En su lugar, monitorea el Write-Ahead Log (WAL) de SQLite y transmite los cambios a un almacenamiento de objetos como S3. Esto proporciona recuperación ante desastres para despliegues de nodo único a un costo mínimo, abordando la necesidad común de copias de seguridad en lugar de clustering en tiempo real. Rqlite responde a la pregunta de alta disponibilidad donde el tiempo de inactividad es inaceptable, mientras que Litestream aborda la durabilidad de los datos para arquitecturas más simples.

Innovaciones más recientes han explorado diferentes puntos del espacio de diseño. Cr-sqlite introduce Tipos de Datos Replicados Sin Conflictos (CRDTs) como una extensión de SQLite, permitiendo que múltiples escritores diverjan y fusionen cambios sin un líder central. Este enfoque AP (Disponibilidad y Tolerancia a Particiones) se adapta bien a aplicaciones locales donde la consistencia inmediata es menos crítica que la capacidad offline. Mientras tanto, proyectos como libSQL bifurcaron el propio motor de SQLite para habilitar integraciones más profundas, impulsando servicios como Turso que ofrecen bases de datos replicadas en el edge como producto gestionado.

Detalles clave

• Rqlite se lanzó en septiembre de 2014, utilizando inicialmente la librería goraft antes de cambiar a la implementación de Raft de Hashicorp a principios de 2016.
• Dqlite de Canonical, creado en 2017, es una librería C incrustada en aplicaciones, mientras que rqlite opera como un servidor independiente.
• Litestream, lanzado en 2021, transmite archivos WAL de SQLite a S3 para recuperación ante desastres sin usar protocolos de consenso.
• Cr-sqlite habilita soporte multi-escritor mediante CRDTs, atendiendo a aplicaciones locales que requieren consistencia eventual.
• Turso, construido sobre la bifurcación libSQL, fue adquirido por Supabase en 2026, destacando la viabilidad comercial de SQLite distribuido gestionado.
• Cloudflare D1 y Durable Objects representan el cambio hacia la replicación de SQLite serverless y gestionada en el edge.

Por qué importa

Para ingenieros de software y líderes de infraestructura, entender la historia de SQLite distribuido aclara los compromisos entre diferentes patrones arquitectónicos. La emergencia de tres rincones distintos en el espacio de diseño—clustering basado en consenso, streaming de WAL y fusión de CRDTs—significa que elegir una solución requiere una definición precisa de los requisitos. Los desarrolladores deben decidir si necesitan fuerte consistencia con alta disponibilidad, recuperación ante desastres rentable o capacidades de colaboración offline-first. Aplicar incorrectamente un sistema CP como rqlite a un caso de uso que solo necesita copias de seguridad, o viceversa, puede llevar a complejidad innecesaria o riesgos de datos.

La trayectoria desde herramientas de código abierto hasta plataformas gestionadas también refleja una tendencia más amplia en el software de infraestructura. Mientras que rqlite, dqlite y Litestream siguen siendo gratuitos y de código abierto, el significativo capital de riesgo y las adquisiciones han flujido hacia servicios que abstraen la complejidad operativa. Empresas como Turso y Cloudflare venden SQLite replicado como una utilidad, permitiendo a los equipos evitar la carga de mantenimiento de gestionar clústers. Este cambio valida la tecnología subyacente pero altera el modelo económico para desarrolladores que previamente dependían de soluciones autoalojadas.

Qué puedes hacer

• Evalúa tus requisitos de consistencia: elige sistemas basados en Raft como rqlite para fuerte consistencia, o CRDTs como cr-sqlite para apps offline-first.
• Considera Litestream si tu necesidad principal es la recuperación ante desastres para una base de datos SQLite de nodo único en lugar de clustering en tiempo real.
• Usa dqlite si estás construyendo una aplicación que requiere una base de datos replicada incrustada sin dependencias de servicios externos.
• Explora servicios gestionados como Turso o Cloudflare D1 si deseas descargar la sobrecarga operativa de gestionar clústers de bases de datos distribuidas.
• Revisa las capacidades de streaming de WAL en rqlite v8.0, inspiradas en Litestream, para optimizar los procesos de copia de seguridad y recuperación.
• Evalúa si tu equipo tiene la experiencia para mantener un clúster Raft autoalojado o si una plataforma gestionada ofrece una mejor asignación de recursos.