El 11 de julio de 2026, un sitio llamado Lobsters hizo algo que suena contraintuitivo: cambió el sistema de base de datos de pago que había usado durante más de una década (un software comercial llamado MariaDB, que requiere alquilar un servidor aparte para funcionar) por una base de datos completamente gratuita: SQLite. Puedes entender esta última como una base de datos «basada en archivos»: no necesita un servidor propio, no genera facturas adicionales y funciona con unas pocas líneas de código.
Dos días después, un lunes por la mañana, uno de los mantenedores del sitio publicó en la propia web: el uso de CPU había bajado, el consumo de memoria había bajado y las páginas cargaban con más fluidez. La frase clave: «Cuando el servidor de MariaDB se dé de baja del todo, la factura mensual del VPS se reducirá directamente a la mitad.»
En los círculos de programadores, esta publicación explotó. 384 votos, 92 comentarios. No porque la técnica fuera deslumbrante; todo lo contrario, porque el asunto era demasiado sencillo.
Un dilema de base de datos que duró siete años
Antes de contar esta migración, digamos brevemente qué es Lobsters. Es un sitio de «compartir enlaces + discusión» para programadores, parecido a un Hacker News más tranquilo y más técnico. Los usuarios comparten artículos técnicos y otros votan y comentan. El sitio no es grande —el archivo de la base de datos ocupa unos 500 MB y el tráfico diario lo aguanta un servidor normal—, pero lleva más de una década funcionando de forma estable.
El problema estaba en la base de datos que usaba. En sus inicios, Lobsters eligió MariaDB, un sistema de base de datos comercial que requiere un servidor independiente para funcionar. Con el tiempo, el equipo fue viendo que esa solución era demasiado pesada: un servidor más significa una factura mensual más y un punto de fallo potencial más que mantener. En agosto de 2018, el mantenedor principal, pushcx, abrió un hilo de discusión en GitHub titulado «Discutir la migración a PostgreSQL», otra base de datos de pago.
El hilo se quedó ahí durante siete años, y la dirección fue derivando de PostgreSQL hacia SQLite. El verdadero giro llegó a principios de 2025: el grupo inversor K1 adquirió MariaDB, lo que sembró dudas en la comunidad sobre las perspectivas a largo plazo de MariaDB. Al mismo tiempo, un miembro de la comunidad llamado Rahul preguntó en el hilo: «¿Podría Lobsters funcionar sobre SQLite?»
¿Qué es SQLite? En una frase: una base de datos gratuita que guarda todos los datos en un archivo local. No necesita instalación, ni configuración, ni un servidor aparte. Está integrada en el navegador Chrome, en WeChat y en cada una de las apps de tu teléfono; es el motor de base de datos más instalado del mundo. Pero durante mucho tiempo se dio por sentado que «no era apta para sitios web», porque su diseño difiere del de los sistemas de base de datos tradicionales que requieren un servidor independiente (MariaDB, PostgreSQL, MySQL).
Aquella pregunta de Rahul derribó ese supuesto por defecto.
La primera migración: la CPU se disparó al 100 % y hubo que revertir de urgencia
En junio de 2025, un contribuidor de la comunidad llamado thomas0 asumió oficialmente el trabajo de migración. En la publicación dejó un relato de una franqueza poco común: todo el proceso pasó por tres intentos de commit de código, un despliegue fallido y, tras corregir tres problemas, finalmente lo logró.
El primer despliegue ocurrió el 21 de febrero de 2026. thomas0 y pushcx hablaron por teléfono y elaboraron una lista de despliegue detallada; todo avanzaba según lo previsto, hasta el momento en que el nuevo código entró en producción. El sitio pasó a modo de solo lectura (una medida de protección para evitar que los datos se corrompieran), pero con solo atender las solicitudes de navegación de los usuarios, toda la CPU del servidor se disparó al 100 %. Se colgó. Los dos investigaron durante un buen rato sin encontrar la causa. Decisión final: revertir.
thomas0 escribió en la publicación: «Después de aquel fracaso me sentí bastante mal.» Porque él ya sabía de antemano que, al no tener acceso a la base de datos de producción, los problemas de rendimiento podían ser un riesgo oculto, y su sospecha se confirmó.
En el análisis posterior, los problemas resultaron estar en tres puntos. En dos de ellos, SQLite ejecutaba un «escaneo completo de tabla» sobre las dos tablas más grandes de la base de datos: como buscar un libro en una biblioteca empezando por el primer estante y hojeándolo uno a uno, sin consultar el catálogo por número. Con pocos datos no pasa nada; con muchos datos, cada vez que alguien abre una página el servidor tiene que leer la tabla entera de principio a fin, y la CPU se satura. El tercer punto era un patrón ineficiente llamado «consulta N+1»: por cada dato que se consulta, el programa lanza N consultas adicionales. Lo correcto es traer de una sola vez todos los datos necesarios.
Tres problemas: dos en la forma de escribir el SQL y uno en la lógica del programa. Ninguno era un defecto de SQLite en sí; es que entre dos sistemas de base de datos distintos, el mismo código puede producir una eficiencia de ejecución radicalmente diferente.
La segunda migración: un lunes tranquilo por la mañana
Tras el rollback del 21 de febrero, thomas0 tardó solo dos días en enviar la tercera modificación. ¿Qué hizo?
Primero, corrigió los dos problemas de escaneo completo de tabla detectados en el primer despliegue: añadió los índices adecuados a las consultas, lo que equivale a crear un catálogo de búsqueda rápida para esas «grandes tablas». Para quien conoce las bases de datos, esto es lo básico; pero en un escenario de migración, el punto clave es este: en MariaDB, esas consultas quizá seguían una ruta de ejecución distinta, por lo que el problema de rendimiento nunca había salido a la luz. Al pasar a SQLite, con las mismas sentencias de consulta, SQLite eligió otra estrategia de ejecución: escanear toda la tabla. Al cambiar la base de datos, el «buen código» de antes se convirtió en «mal código».
Segundo, corrigió la consulta N+1: cambió las consultas en bucle por consultas por lotes. El programa dejó de preguntar a la base de datos dato por dato y pasó a extraer de una sola vez todos los datos necesarios.
Tercero, dedicó una semana a generar, con un script propio y de forma local, datos de prueba equivalentes a la mitad del volumen real de datos de Lobsters, porque, al no poder acceder a los datos reales de producción, esa era la única manera de simular el tráfico. Ese script fue, en sí mismo, una carga de trabajo de ingeniería adicional.
Cuarto, por seguridad, antes del despliegue añadió un interruptor de «registro de consultas lentas»: por si quedaba algún problema de rendimiento sin detectar, el sistema registraría automáticamente las consultas que tardaran más de 100 milisegundos, para poder localizarlas rápidamente.
El 11 de julio de 2026 llegó el segundo despliegue. Esta vez el desenlace fue distinto. El sitio siguió funcionando con normalidad y las curvas de CPU y memoria se mantuvieron estables. Vigilaron las reacciones de los usuarios en el canal de chat, resolvieron dos pequeños problemas y esperaron al lunes: la verdadera prueba del pico de tráfico.
El lunes por la mañana, todo transcurrió en calma. pushcx dijo en el chat interno: «Hemos tenido un lunes tranquilo.»
¿Por qué una base de datos «más simple» resulta ser mejor?
Lo contraintuitivo de esta historia está aquí: SQLite es mucho más «rudimentaria» que MariaDB. No tiene sistema de permisos de usuario, no admite grandes volúmenes de escritura simultánea, no se puede acceder a ella de forma remota por red y no soporta muchas sintaxis de consulta avanzadas. Pero, tras el cambio, todo mejoró en Lobsters.
Hay tres capas de razones.
Primera capa: un servidor menos, un montón de problemas menos. En la arquitectura anterior, el programa del sitio de Lobsters corría en un servidor y la base de datos MariaDB corría en otro. Las dos máquinas necesitaban comunicarse por red, y había que mantenerlas, respaldarlas y monitorizarlas por separado. SQLite convirtió la base de datos en un archivo dentro del propio programa del sitio: los datos residen en la misma máquina y hacer una copia de seguridad es copiar un archivo. Para un sitio como Lobsters, capaz de sostener todo su tráfico con un solo servidor, un servidor de base de datos independiente no es un activo, es un pasivo.
Segunda capa: eliminar la latencia. Cada vez que un usuario abre una página, el programa del sitio necesita consultar la base de datos. En la arquitectura de MariaDB, esa consulta pasa por un recorrido de ida y vuelta: «programa → red → servidor de base de datos → red → programa». Con SQLite, la consulta se convierte en «programa → archivo local», y la variable de la latencia de red desaparece por completo. Para un sitio con muchas lecturas y pocas escrituras —como un sitio de compartir enlaces—, la mejora de velocidad de respuesta que aporta este cambio es muy real.
Tercera capa: el coste. Esta es la más evidente. El alquiler mensual del servidor de MariaDB ya no hay que pagarlo. La factura del VPS se reduce a la mitad directamente. No es un abstracto «reducir costes y aumentar la eficiencia»: es un número menos en la factura.
thomas0 también enumeró en la publicación algunos detalles técnicos: SQLite no admite enteros grandes sin signo, así que hubo que cambiar el tipo de ciertos campos de ID; las reglas de ordenación de SQLite son más débiles que las de MariaDB, solo admiten la insensibilidad a mayúsculas y minúsculas de caracteres ASCII y no manejan el tratamiento en UTF-8 completo; usaron funciones definidas por el usuario para suplir algunas funciones de cálculo que le faltan a SQLite. Estos detalles no le importan al lector común, pero ilustran una idea: la esencia de una migración es encontrar, entre dos sistemas, un nuevo conjunto de rutas que permita que todas las funciones sigan operando con normalidad.
«Que baste con lo suficiente» frente al «culto a la complejidad» de la industria del software
La verdadera razón por la que esta historia merece ser más conocida no está en lo técnico. Toca un hábito profundamente arraigado en la industria del software: elegir por defecto la solución «grande y completa» en lugar de la solución «suficiente».
Lobsters eligió MariaDB al principio porque, en aquel momento, la práctica estándar para hacer un sitio web era «aplicación + servidor de base de datos independiente». Esa arquitectura era razonable hace más de una década: entonces las expectativas de crecimiento de los sitios eran altas, el tráfico fluctuaba mucho y se necesitaba que la base de datos tuviera capacidad de amortiguación. Pero pasaron más de diez años y la escala de Lobsters no experimentó un cambio cualitativo. Sigue siendo un sitio comunitario de tamaño pequeño o mediano, cuyo tráfico diario aguanta un servidor normal. Sin embargo, aquel servidor de base de datos «por si acaso» generaba un gasto fijo mensual constante.
No es un caso aislado. En la industria del software existe un error común llamado «optimización prematura»: pagar por adelantado por una escala que aún no ha llegado. Un equipo de startup, siendo tres personas, ya monta un clúster de Kubernetes, una arquitectura de microservicios y una base de datos maestro-esclavo, solo «para poder escalar en el futuro». Esas decisiones no son erróneas en sí, pero el precio es un triple aumento: en complejidad operativa, en factura mensual y en dificultad para diagnosticar fallos.
A un nivel más profundo, quien escribe quiere señalar esto: lo «avanzado» y lo «adecuado» de una tecnología son dos cosas distintas. Una base de datos ligera, gratuita y que guarda los datos en un archivo, es cierto que en su tabla de funciones no luce tanto como una base de datos comercial. Pero si no necesitas esas funciones de más —como permisos multiusuario, replicación en ubicaciones remotas o escritura concurrente masiva—, entonces esas funciones no son un activo, son un lastre.
Por supuesto, esto no significa que SQLite sea adecuada para todos los escenarios. El propio thomas0 reconoció, en los comentarios y en sus discusiones con otros usuarios, que si un sitio tiene una gran necesidad de escrituras simultáneas, requiere que varios servidores accedan a la vez a los mismos datos o necesita una gestión compleja de permisos de usuario, SQLite no es la opción adecuada. Su modelo de concurrencia es «múltiples lecturas, una sola escritura»: que muchas personas miren a la vez no supone problema, pero en un mismo instante solo puede haber una escribiendo datos. Para una comunidad como Lobsters, donde «los usuarios navegan mucho más de lo que publican», eso no es un problema. Para Taobao o WeChat, sería un desastre.
La clave está en el acto de examinar qué necesitas realmente. Ese juicio importa más que el número de versión de la base de datos que elijas.
Para terminar
Desde que pushcx abrió aquel hilo de discusión en agosto de 2018 hasta el éxito del segundo despliegue el 11 de julio de 2026, la migración de base de datos de Lobsters abarcó casi ocho años. Por el camino hubo un fracaso, tres modificaciones de código, un script de prueba escrito por ellos mismos, una herramienta de migración de base de datos escrita por ellos mismos, e innumerables discusiones y aquel «¿por qué no lo intentamos otra vez?» en el canal de chat.
El resultado final es tan simple que se cuenta en una frase: una veterana comunidad técnica que lleva más de una década funcionando cambió su base de datos, de un sistema comercial que requería un servidor independiente, a una base de datos gratuita basada en archivos. La factura del servidor se redujo a la mitad. El lunes por la mañana estuvo muy tranquilo.
No es una historia sobre «disrupción». Es una historia sobre «volver a lo suficiente».
Enlaces de referencia
- Publicación en Lobsters: ahora funcionando sobre SQLite (publicada por thomas0)
- GitHub issue #539: historia completa de la migración de MariaDB a PostgreSQL/SQLite
- Reportaje de Simon Willison: Lobsters ha migrado a SQLite
- Gist de la lista de despliegue de pushcx: pasos completos de las dos puestas en producción
- Repositorio de código abierto de Lobsters (GitHub)