El sitio comunitario Lobsters completó el fin de semana la migración de MariaDB a SQLite, cerrando un proceso iniciado en 2018 que primero apuntaba a PostgreSQL. Ahora el sitio corre en un único VPS con cuatro bases de datos SQLite: contenido principal (3.8 GB), caché (1.1 GB), colas (218 MB) y Rack::Attack para rate limiting (555 MB). CPU y memoria en baja, costos reducidos a la mitad, y el sitio más ágil según quienes lo usan.

Te importa porque demuestra un patrón arquitectónico contracorriente: no hace falta un RDBMS tradicional para un sitio que sirve a una comunidad activa. SQLite con la arquitectura correcta aguanta cargas de producción que muchos todavía asocian a sistemas más complejos. Para quien construye con agentes, es un caso concreto de cuánto se puede hacer con un único servidor y SQLite, como contábamos el 14 de julio con DOOMQL.

El patrón se aplica: si tu sistema tiene muchas escrituras concurrentes sobre el mismo dato, SQLite probablemente no es suficiente. Pero si escribes en bases de datos separadas por función (como Lobsters hace con contenido, caché, colas y rate limiting), la sencillez operativa compensa.

En detalle

El contexto

Lobsters había planeado salir de MariaDB desde 2018, inicialmente hacia PostgreSQL. En 2025 decidieron en cambio evaluar SQLite, y este fin de semana la migración pasó a producción.

La arquitectura

El sistema ahora corre en un único VPS y usa cuatro bases de datos SQLite separadas, cada una con una responsabilidad:

• Contenido principal (3.8 GB): historias, comentarios, votos, usuarios
• Caché (1.1 GB): capa de aceleración
• Colas (218 MB): trabajos asincronos
• Rack::Attack (555 MB): rate limiting y bloqueo de solicitudes abusivas

La separación por función evita la contención en escrituras concurrentes, el límite más conocido de SQLite. Cada base de datos puede crecer e hacer vacuum independientemente.

El trabajo detrás

La migración está documentada en el PR #1949 de Thomas Dziedzic: 30 commits, 188 archivos tocados, +735/-593 líneas. Se apoya en tres PRs previos (#1705, #1871, #1924) que habían preparado el terreno. El código Rails fue adaptado, los tests verificados, el proceso de deploy rescrito.

Qué cambió para quienes la usan

Los números reportados por el equipo:

• Uso de CPU en baja
• Uso de memoria en baja
• Latencia percibida mejor
• Costos operativos reducidos a la mitad (una vez apagado el VPS MariaDB)

Sin benchmarks formales, pero el efecto es bastante evidente como para considerar la migración permanente.

Cuándo SQLite no es suficiente

SQLite tiene un modelo de concurrencia simple: solo un proceso escribe por vez en una base de datos. Si tu aplicación tiene múltiples procesos escribiendo sobre el mismo dato simultáneamente, se convierte en un cuello de botella. Lobsters lo evita separando las escrituras por base de datos y aprovechando la caché para reducir presión en el contenido principal.

Si tu carga tiene escrituras frecuentes y concurrentes sobre el mismo dataset, PostgreSQL o MariaDB siguen siendo mejores opciones. Pero si puedes particionar por función como Lobsters, o si tus escrituras son serializables, SQLite aguanta cargas sorprendentes.

Implicaciones para quien construye

Esta migración es un caso de estudio para quien diseña sistemas que usan agentes: un agente que lee y escribe en SQLite local puede evitar la complejidad de una base de datos remota, con latencia y costos operativos menores. Si la arquitectura separa responsabilidades (una base de datos para sesiones, otra para resultados, otra para logs), el modelo single-writer de SQLite no es una limitación sino una garantía de consistencia.

Para profundizar en el uso de SQLite en arquitecturas de agentes, ve el scaffolding del sitio estático multilingüe y el asistente de análisis de datos, ambos construidos sobre SQLite.