Malentendidos sobre SQLite-on-the-Server: más adecuado para escala hipermasiva que para pequeña escala

• Muchos desarrolladores piensan que usar SQLite en el servidor solo encaja en aplicaciones pequeñas
• Las razones suelen ser las siguientes:
  • Bajo costo de infraestructura: no se necesita un servidor de base de datos separado (funciona con un solo archivo)
  • Facilidad para desarrollo y pruebas: el mismo archivo de BD puede usarse tanto en cliente como en servidor
  • Carga operativa mínima: no hacen falta configuraciones complejas ni administrar daemons
  • Alta confiabilidad: SQLite es la BD más distribuida del mundo y ofrece una gran durabilidad
• Herramientas como LiteFS, Litestream, rqlite, Dqlite, Bedrock agregan replicación y alta disponibilidad (HA) a SQLite, haciéndolo adecuado para despliegues pequeños

Pero este artículo explora el potencial de SQLite no para aplicaciones pequeñas, sino para aplicaciones de escala hipermasiva (Hyper-Scale)

Problemas de escalado en las grandes bases de datos tradicionales

• Las aplicaciones grandes normalmente tienen dificultades para mantener PostgreSQL o MySQL como una sola BD, por lo que usan bases de datos con sharding
• Ejemplos: Cassandra, ScyllaDB, DynamoDB, Vitess (MySQL con sharding), Citus (Postgres con sharding)
• Las BD con sharding tienen ventajas como:
  • Optimización de lecturas por lotes (Batch Read) mediante particionado de datos
  • Escalado horizontal (Scalability)
  • Alto rendimiento de escritura

Pero las soluciones actuales de particionado tienen las siguientes desventajas

• Esquemas rígidos (Rigid Schemas): no soportan consultas flexibles como MySQL o Postgres
• Dificultad para cambiar el esquema: agregar índices o modificar relaciones implica una gran carga operativa
• Operaciones complejas entre particiones: es difícil mantener transacciones ACID, y se requieren técnicas complejas como two-phase commit (2PC)
• Problemas de inconsistencia de datos: es difícil aplicar restricciones fuertes entre particiones, y hay mayor riesgo de perder consistencia

El potencial de una base de datos hiperescalable basada en SQLite

• Cloudflare Durable Objects y Turso muestran una forma de diseñar aplicaciones hiperescalables basadas en SQLite
• Estos sistemas ofrecen fortalezas como:
  • Escalado dinámico (Dynamic Scaling): crean bases de datos por entidad (Entity), reduciendo la complejidad de infraestructura
  • Bases de datos ilimitadas y de bajo costo: en lugar de forzar particiones de datos como en el sharding tradicional, permiten crear nuevas instancias de SQLite cuando se necesiten
  • Distribución global (Global Distribution): ubican la base de datos cerca del usuario para mejorar el rendimiento
  • Replicación y durabilidad integradas (Built-in Replication & Durability): a diferencia de SQLite tradicional, replican datos entre múltiples regiones para mantener alta disponibilidad
• Forma de reemplazar el sharding usando SQLite (con Cloudflare Durable Objects y Turso)
  • En el sharding tradicional, varios logs de chat se almacenan dentro de una sola partición de base de datos
  • Con SQLite, se puede crear una base de datos SQLite independiente para cada canal, permitiendo usar esquemas más flexibles
  • Estructura de ejemplo
    • Sharding tradicional: tabla de logs de chat + clave de partición
    • Basado en SQLite: BD SQLite individual por canal (incluye logs de chat, participantes y reacciones)
• Las ventajas de este enfoque con SQLite son las siguientes:
  • Mantiene transacciones ACID locales: permite ejecutar transacciones dentro de cada BD individual sin problemas entre particiones
  • I/O de alto rendimiento: como SQLite es una BD de archivo único, el rendimiento de lectura y escritura es excelente
  • Posibilidad de aprovechar extensiones SQL:
    • FTS5 (Full-Text Search): mejora el rendimiento de búsqueda
    • JSON1: soporta almacenamiento y consultas sobre datos JSON
    • R*Tree, SpatiaLite: permiten trabajar con datos espaciales
  • Soporte para migraciones SQL: compatible con herramientas de migración existentes como Prisma y Drizzle
  • Soporte para migraciones de esquema diferidas (Lazy):
    • No es necesario ejecutar la migración de inmediato; se pueden aplicar migraciones ligeras al abrir cada instancia de SQLite

Limitaciones al usar SQLite en el servidor

• Falta de soluciones open source y autohospedables
• No hay soporte para consultas entre bases de datos → para analítica se necesita un data lake separado
• Herramientas de base de datos limitadas (navegadores SQL, pipelines ETL, monitoreo, respaldos)
  • StarbaseDB está resolviendo este problema sobre la base de Cloudflare Durable Objects + SQLite
• Falta de un protocolo estándar unificado
  • PostgreSQL, MySQL y Cassandra usan protocolos estandarizados, pero los servidores SQLite todavía carecen de un protocolo de red estandarizado
• Faltan casos de uso a gran escala con SQLite en hiperescalado
  • Todavía faltan estudios de caso como los de Cassandra o DynamoDB, aunque esto podría cambiar con el tiempo

Conclusión: SQLite no es solo una BD local simple, sino una opción poderosa también para aplicaciones hiperescalables

• SQLite no es solo una BD para proyectos pequeños, sino una herramienta potente que puede reemplazar enfoques tradicionales de sharding incluso en aplicaciones hiperescalables
• Con Cloudflare Durable Objects & Turso, es posible dividir la base de datos por entidad y escalar manteniendo las potentes capacidades de SQL y las transacciones ACID
• Tiene altas probabilidades de consolidarse como una alternativa más flexible y fácil de administrar que las bases de datos tradicionales con sharding

[pcj9024]

Quién será el valiente que usaría con gusto sqlite a una escala hipermasiva capaz de soportar muchísimas solicitudes...

[GN⁺]

Comentarios de Hacker News

• Un usuario está considerando reemplazar una base de datos personalizada por SQL

  • Sqlite3 se considera como candidato porque corre en un solo servidor
  • La base de datos tiene principalmente cargas de lectura, así que Sqlite3 resulta favorable
  • La base de datos personalizada es muy rápida en tareas específicas, pero es una decisión compleja
  • Se comparó Sqlite3 con Postgresql mediante pruebas de benchmark
  • Sqlite3 fue aproximadamente dos veces más rápido que Postgresql en todas las tareas
  • La base de datos personalizada fue entre 100 y 1,000 veces más rápida que Sqlite3 en acceso a un solo registro

• Un usuario está desarrollando una app web local-first y cree que SQLite es una buena opción

  • Quiere una forma sencilla de sincronizar el estado de la base de datos SQLite con un servicio en la nube
  • Turso y SQLite Cloud parecen opciones prometedoras
  • Está considerando un enfoque simple donde el usuario pueda hacer push a almacenamiento S3

• Se discuten las ventajas de SQLite-Per-Partition

  • Hay limitaciones en situaciones donde se necesitan tablas globales
  • Se comparten experiencias de varios proyectos usando SQLite

• En entornos multiusuario, SQLite enfrenta dificultades por la falta de MVCC

  • Preguntan por implementaciones y extensiones compatibles con sqlite que agreguen MVCC

• Ruby on Rails amplió el soporte para SQLite en su lanzamiento 8.0

  • Reemplaza componentes de caché y cola de trabajos, y lo vuelve adecuado para apps web comunes

• A un usuario que no está familiarizado con Vitess o Citus le cuesta entender el contenido del artículo

  • Tiene curiosidad por la diferencia entre Sharded Sqlite y Sharded Postgres

• Un usuario no quería hospedar un VPS, así que creó una página web usando SQLite

  • Descarga la base de datos al dispositivo del usuario para usarla

• Un usuario que tuvo dificultades configurando un controlador de Ubiquiti sugirió usar SQLite

  • Cree que usar SQLite en lugar de MongoDB podría ofrecer una mejor experiencia

• Apple opera alrededor de 300,000 instancias de Cassandra/ScyllaDB según datos de 2022

  • Considera que el enfoque DB-per-tenant avanza en una mejor dirección

• TDLib (la biblioteca de base de datos de Telegram) usa SQLite

  • Cada instancia de TDLib maneja simultáneamente más de 24,000 bots activos