Elegir motor de base de datos es una de las decisiones más caras de revertir, porque cuando te das cuenta de que te quedó chico ya tienes datos de usuarios reales adentro.
Estas seis preguntas llevan a una de cuatro respuestas: SQLite, PostgreSQL, MySQL o un proveedor gestionado. Ninguna requiere saber de bases de datos, solo conocer tu proyecto.
La comparación técnica detallada de los tres motores está en SQLite vs PostgreSQL vs MySQL. Este artículo es el atajo para decidir.
Antes de empezar
Las seis preguntas se responden en orden y cada una puede descartar opciones para las siguientes. La dos y la cinco son las únicas que deciden por sí solas.
Si no sabes la respuesta a alguna, esa incertidumbre también es información: significa que conviene elegir la opción más fácil de cambiar después, no la más completa.
Las dos últimas preguntas no son técnicas, y son las que más caro salen si se saltan.
Las dos últimas preguntas no son técnicas y son las que más caro salen si se saltan: cuánto vas a pagar cuando el proyecto crezca, y qué costaría llevarte los datos a otro lado.
¿Cuántas escrituras por segundo, no cuántos usuarios?
La pregunta que importa no es cuánta gente usa el sistema, es cuántas veces por segundo alguien guarda algo. Un sitio con mil visitas diarias que solo lee contenido escribe muy poco.
Cuenta lo que genera una escritura real: un registro nuevo, un comentario, un pedido, un cambio de estado. Las visitas que solo consultan no cuentan.
Menos de una escritura por segundo en promedio: SQLite alcanza. Decenas por segundo o picos concentrados: necesitas un servidor, sigue a la pregunta 3.
¿Va a haber más de un servidor de aplicación?
Esta pregunta descarta SQLite por sí sola, sin importar la respuesta anterior.
SQLite vive en el disco de una máquina concreta. Si mañana necesitas dos servidores atendiendo peticiones, o si tu plataforma de despliegue levanta y apaga instancias sola, no hay forma directa de que todas escriban en el mismo archivo.
Si la respuesta es sí, o no lo sabes: descarta SQLite aquí y sigue. Si es un solo servidor y va a seguir siéndolo: SQLite sigue en carrera.
¿Quieres administrar un servidor de base de datos?
Administrar significa instalarlo, configurarlo, actualizarlo, vigilar que no se llene el disco, y sobre todo hacer copias de seguridad y probar que se pueden restaurar.
Si la respuesta es no, y para la mayoría de los proyectos que arrancan con una sola persona debería serlo, un proveedor gestionado te da PostgreSQL o MySQL ya configurado con copias incluidas.
El costo típico arranca en unos pocos dólares al mes y muchos tienen capa gratuita para empezar. A cambio ganas tiempo que no vas a gastar aprendiendo a administrar un motor.
No quieres administrarlo: proveedor gestionado. Sí quieres, o ya tienes un servidor andando: instalación propia.
¿Tu stack ya asume un motor?
Antes de comparar funciones conviene mirar qué da por sentado lo que ya usas. Si tu proyecto vive sobre WordPress o un CMS clásico, MySQL es el camino con menos fricción y no hay motivo para pelearse con eso.
Lo mismo aplica al hosting: en hosting compartido MySQL casi siempre viene incluido y PostgreSQL rara vez, así que el entorno puede decidir por ti antes que cualquier criterio técnico.
El stack ya asume uno: úsalo, salvo que la pregunta 5 diga lo contrario. Empiezas de cero: PostgreSQL es la apuesta más segura a largo plazo.
¿Necesitas algo que solo un motor hace bien?
Hay casos donde la decisión se toma sola porque un motor resuelve algo que el otro no. Los más frecuentes son búsqueda de texto completo en serio, datos geográficos, y búsqueda por vectores para funciones de IA.
En los tres, PostgreSQL lleva ventaja clara por sus extensiones. Si tu proyecto necesita alguna, deja de comparar y elige PostgreSQL.
La advertencia va en el otro sentido: apoyarte en extensiones específicas es también lo que encarece cambiar de motor después. Vale la pena hacerlo a conciencia y no por descubrir una función entretenida.
Necesitas alguna de esas: PostgreSQL. No las necesitas hoy: no es razón suficiente para descartar las demás opciones.
¿Qué tan difícil sería cambiar de opinión en un año?
Es la pregunta de control, y conviene hacerla aunque las cinco anteriores ya hayan dado una respuesta.
Si te apegas a SQL estándar y evitas funciones propias de un motor, migrar es un trabajo acotado y no la reescritura que la gente imagina. Migrar de SQLite a PostgreSQL cuando el proyecto crece es un camino transitado.
Lo que sí duele es haber diseñado alrededor de algo que solo existe en un motor. Por eso la decisión real no es cuál de los cuatro nombres eliges, sino cuánto te atas a él.
Sea cual sea tu respuesta, escríbela junto con el motivo. Dentro de un año esa línea vale más que volver a razonarlo todo desde cero.
¿Cuánto vas a pagar de verdad al mes?
Los planes gestionados se comparan por el precio de entrada, que suele ser bajo o gratuito. El número que importa es otro: qué pasa cuando cruzas el primer límite.
Tres cosas se cobran aparte con frecuencia y no aparecen en la portada: el almacenamiento por encima de la cuota, la transferencia de datos hacia afuera, y las copias de seguridad con retención larga.
Hay además una práctica común en las capas gratuitas que conviene conocer: suspender la base cuando no recibe consultas por un rato. Eso está bien para un proyecto en desarrollo, y bastante mal para uno con usuarios reales, porque la primera visita después de la pausa espera varios segundos.
Si el presupuesto es ajustado: SQLite sobre el hosting que ya pagas cuesta cero. Si puedes pagar: revisa el precio del segundo escalón, no el del primero.
¿Cómo sacarías tus datos de ahí?
Es la pregunta que casi nadie hace al elegir y la que define cuán atado quedas. No se trata de desconfiar del proveedor, sino de saber que la puerta existe.
Lo que conviene verificar antes de comprometerse es concreto: si puedes generar un volcado completo cuando quieras, en qué formato sale, y si se puede restaurar en un servidor propio sin herramientas del proveedor.
Con PostgreSQL y MySQL la respuesta suele ser sí, porque el volcado es estándar. Con plataformas que envuelven la base en su propia capa de servicios, la base sale, pero la autenticación, los permisos y las funciones que construiste encima se quedan.
Prueba concreta: haz un volcado y restáuralo en tu máquina una vez, al principio, cuando no hay datos que perder. Si no puedes, ya sabes el costo de salir.
Por qué esta decisión se toma mal tan seguido
Hay tres razones que se repiten, y ninguna tiene que ver con desconocer los motores.
Se compara por potencia en vez de por encaje. Puesto uno al lado del otro, el motor con más funciones siempre parece la opción responsable. Pero elegir por funciones que no vas a usar es pagar operación a cambio de nada.
Se confunde el tamaño de los datos con la concurrencia. Es el error específico que hace que la gente descarte SQLite. La pregunta no es cuántos datos vas a guardar, es cuántas veces por segundo vas a escribirlos.
Se decide una sola vez y no se vuelve a mirar. La elección correcta para el mes uno puede dejar de serlo en el mes doce, y casi nunca hay un momento asignado para revisarla.
Las señales de que te quedó chico
Cambiar de motor antes de tiempo es desperdicio, y hacerlo tarde es doloroso. Estas son las señales concretas de que llegó el momento, en orden de aparición.
Errores de base bloqueada bajo carga. En SQLite, si aparecen después de haber activado WAL y un busy_timeout razonable, ya no es un problema de configuración.
Necesitas un segundo servidor de aplicación. No es una señal gradual: es el punto donde SQLite deja de ser viable, sin importar cuán bien vaya.
Las copias de seguridad ya no caben en la ventana. Cuando respaldar empieza a afectar el servicio, necesitas un motor con herramientas pensadas para eso.
Tu consulta más frecuente se volvió lenta y los índices ya no alcanzan. Ojo con esta: nueve de cada diez veces sigue siendo un índice que falta, no el motor.
Esa última merece énfasis porque es la que más migraciones innecesarias provoca. Antes de cambiar de motor por lentitud, conviene revisar el plan de ejecución de la consulta que duele. Está explicado en la comparativa de los tres motores.
Dos casos donde el árbol no aplica
Hay situaciones en las que ninguna de las seis primeras preguntas manda, porque la decisión ya está tomada por fuera.
El proyecto es un encargo de un cliente que ya tiene infraestructura. Si el cliente opera sobre un motor concreto, con su equipo y sus copias de seguridad, llevarle un motor distinto le agrega una pieza que nadie va a mantener cuando tú no estés. Ahí la respuesta correcta es la que ya usan, aunque técnicamente prefieras otra.
Estás construyendo algo que se instala en el equipo de otra persona. Una aplicación de escritorio, una herramienta de línea de comandos, un programa que corre en el dispositivo de un usuario. Pedirle a alguien que instale y administre un servidor de base de datos para usar tu programa no es una opción realista, y ese es justamente el terreno donde SQLite no tiene competencia.
En ambos casos conviene registrar por qué se decidió así. Una elección impuesta por el contexto se ve idéntica a una elección descuidada cuando alguien la revisa meses después, y la diferencia entre las dos importa.
Qué hacer con la respuesta
Cuando llegues a una de las cuatro, escríbela en el repositorio junto con el motivo y la fecha. Dos líneas alcanzan.
## Base de datos
SQLite con WAL. Un solo servidor, menos de 1 escritura/seg,
nadie para administrar un servidor. Revisar si aparece un
segundo servidor de aplicación o errores de bloqueo.
Esa última frase es la más útil de las tres: deja escrito qué tendría que pasar para reconsiderarlo. Sin ella, la decisión se vuelve permanente por omisión, que es justamente como se llega tarde a una migración.
Las cuatro respuestas posibles
Recapitulando a dónde llevan las seis preguntas:
SQLite. Un solo servidor, pocas escrituras por segundo, cero ganas de administrar nada. Activa WAL desde el primer día.
Proveedor gestionado. No quieres administrar un servidor y esperas crecer. Es la opción por defecto razonable para la mayoría de los proyectos que arrancan con una persona.
PostgreSQL propio. Necesitas extensiones concretas o ya tienes infraestructura y quien la cuide.
MySQL. Tu stack u hosting ya lo asumen. Crea las tablas con utf8mb4, no con utf8.
Una advertencia sobre el atajo más común: cuando le preguntas esto a una IA sin dar contexto, la respuesta casi siempre es PostgreSQL. No porque sea incorrecta, sino porque es la más defendible sin conocer tu caso.
Si acabas de responder que tienes un solo servidor, pocas escrituras y ningunas ganas de administrar nada, esa respuesta genérica te habría costado una factura mensual y un servidor que cuidar, para resolver un problema que no tienes.
