El concepto de SQLite distribuido —utilizar el motor SQLite como capa de almacenamiento mientras se gestiona la replicación a través de protocolos externos— ha evolucionado significativamente desde 2014. Philip O'Toole, el creador de rqlite, señala que el primer sistema de código abierto que combinó el algoritmo de consenso Raft con SQLite se lanzó hace más de una década. Esta elección arquitectónica fue impulsada por la necesidad de una pequeña cantidad de almacenamiento relacional en un sistema en clúster donde ningún nodo individual era el anfitrión permanente ideal. Al colocar un registro Raft frente a SQLite, el sistema garantiza que cada escritura se replique en todo el clúster, evitando la pérdida de datos si un solo nodo falla.

A lo largo de los años, la tecnología se ha ramificado en tres esquinas de diseño distintas basadas en diferentes requisitos de consistencia y disponibilidad. La primera esquina, representada por rqlite y dqlite de Canonical, se centra en sistemas CP (Consistencia y Tolerancia a Particiones). Estos utilizan un modelo de consenso basado en un líder donde las escrituras deben ser confirmadas por una mayoría. La segunda esquina surgió alrededor de 2021 con el auge de la recuperación por streaming, ejemplificada por Litestream. En lugar de un clúster, Litestream supervisa el Write-Ahead Log (WAL) de SQLite y lo transmite a un almacenamiento en la nube como S3, proporcionando recuperación ante desastres para configuraciones de un solo nodo. La tercera esquina involucra la replicación basada en fusión, como cr-sqlite, que utiliza Conflict-free Replicated Data Types (CRDTs) para permitir que múltiples escritores diverjan y se fusionen sin un líder central, atendiendo a aplicaciones de enfoque local primero.

Si bien la tecnología subyacente sigue siendo de código abierto, el mercado se ha desplazado hacia las plataformas gestionadas. Proyectos como Turso (adquirido por Supabase en 2026) y D1 de Cloudflare han transformado el SQLite replicado de un componente de infraestructura auto-desplegado en un producto de base de datos sin servidor. O'Toole observa que, aunque la idea central de usar SQLite como motor de almacenamiento con replicación externa ha sido reinventada por al menos ocho equipos diferentes, la distinción principal hoy en día es si el usuario desea ejecutar la infraestructura por sí mismo o pagar por un servicio gestionado. rqlite sigue siendo una opción principal para aquellos que buscan una base de datos relacional tolerante a fallos que puedan comprender completamente y alojar de forma independiente.