La respuesta corta

Si estás construyendo un SaaS indie y quieres un valor por defecto que no te pase factura más adelante, empieza con Postgres gestionado. Hoy es la base de datos relacional open source más adoptada entre desarrolladores profesionales, y todas las grandes plataformas cloud tienen un tier gestionado de Postgres con precio de entrada gratuito o casi gratuito. MySQL gestionado es una buena segunda opción, sobre todo si tu stack ya habla MySQL o te apoyas en un CMS o en workloads analíticos. SQLite no es un juguete, pero tampoco es una base de datos general para SaaS. Úsala donde realmente brilla: productos single-tenant, embebidos o local-first con muchas lecturas.

Esa es la conclusión. El resto de la guía recorre el coste, el techo de migración, los backups y los patrones de workload para que elijas con los ojos abiertos.

Por qué esta decisión pesa más de lo que parece

La base de datos es una de las pocas piezas de un SaaS indie donde una mala elección temprana se acumula en silencio. Cambiar de motor después significa reescribir ORMs, retunear índices, rehacer backups y reexplicarlo todo en la factura del proveedor. Un fundador solitario no tiene una semana libre para eso.

Antes de decidir, conviene tener presente tres tendencias:

  • Postgres tiene impulso. Las encuestas de Stack Overflow llevan varios años mostrando a Postgres como la base de datos más admirada y más deseada entre desarrolladores profesionales; MySQL solo le supera entre quienes aún están aprendiendo.
  • Las plataformas cloud son Postgres-first. Toda plataforma de aplicaciones seria ofrece Postgres gestionado. Eso se traduce en mejores tiers gratuitos, mejor pooling de conexiones y mejores opciones serverless para quien construye en solitario.
  • SQLite ha madurado en silencio. Hoy soporta JSON, columnas generadas y búsqueda full-text. Eso cambia lo que cuenta como un workload realista para ella.

Coste a bajo tráfico, en honesto

Se dice que Postgres gestionado cuesta más que MySQL gestionado. En la práctica, en el tier de entrada de la mayoría de proveedores cuestan más o menos lo mismo. Las diferencias reales vienen de unos cuantos detalles:

  • El pricing por conexiones es la trampa. Postgres usa un proceso por conexión; MySQL es más indulgente y reutiliza hilos. Si tus funciones serverless abren una conexión nueva cada vez, lo pagarás en Postgres antes que en MySQL. Un pooler pequeño lo arregla y es prácticamente obligatorio para Postgres serverless.
  • Los tiers gratuitos existen, pero varían. La mayoría de proveedores cloud ofrecen una instancia pequeña de Postgres gestionado gratis o por pocos dólares al mes, normalmente con tope de almacenamiento y límite de filas o conexiones. Lee la letra pequeña sobre auto-sleeps, topes de filas y de almacenamiento antes de construir encima.
  • El crecimiento del almacenamiento es la fuga lenta. Tanto Postgres gestionado como MySQL gestionado facturan por gigabytes. Conforme crecen tus logs de auditoría, eventos y tablas analíticas, crece la factura. Define una política de retención de 90 días antes de lanzar, no después del primer susto en la factura.
  • SQLite puede ser gratis durante mucho tiempo. Un único archivo SQLite en disco no tiene coste por fila ni por conexión. El coste oculto es operativo: backups, replicación y techos de concurrencia.

Para un SaaS indie pre-lanzamiento o en beta temprana, la respuesta realista más barata suele ser un tier gratuito de Postgres gestionado más un pooler de conexiones. La factura puede ser literalmente cero hasta que tengas usuarios reales.

El techo de migración

Esta es la pregunta que debería mover tu decisión: ¿hasta dónde me lleva esta base de datos antes de tener que migrar?

Postgres gestionado tiene el techo más alto. Soporta JSON cuando lo quieres, búsqueda full-text sin un servicio extra, row-level security cuando finalmente aísles datos entre tenants, columnas generadas, window functions avanzadas y un ecosistema de extensiones profundo. Si tu SaaS necesita de pronto queries geoespaciales, series temporales o búsqueda vectorial, Postgres tiene una extensión para cada uno. Migrar fuera de Postgres rara vez es necesario.

MySQL gestionado tiene un techo algo más bajo en SQL avanzado, pero sigue siendo muy alto para workloads SaaS típicos. Es maduro, bien entendido y excelente para patrones read-heavy y OLTP sencillo. Las principales diferencias frente a Postgres son los range units de window functions, row-level security de fábrica y el ecosistema de extensiones. Para CRUD SaaS normal, no las vas a notar.

SQLite tiene el techo más bajo y lo dice abiertamente. SQLite es single-writer por diseño, así que los workloads con muchas escrituras concurrentes van a chocar con un muro. Las réplicas para escalar lecturas existen, pero no son tan llave-en-mano como en Postgres o MySQL. El techo de SQLite es el límite de disco de una sola máquina y el throughput de un único escritor. Para muchos productos, ese techo es más que suficiente. Para un SaaS multi-tenant con muchos escritores concurrentes, no lo es.

Ergonomía de los backups

Los backups son la parte que los fundadores olvidan hasta que los necesitan. Las tres opciones se comparan aquí de forma muy distinta:

  • Postgres gestionado y MySQL gestionado vienen ambos con point-in-time recovery en la mayoría de tiers gestionados, snapshots diarios automatizados y restauración con un clic a una instancia nueva. Esto es por lo que realmente estás pagando el peaje de gestionado, y merece la pena. No necesitas escribir un script de backups.
  • SQLite exige que traigas tu propia solución de backup. El enfoque ingenuo, copiar el archivo, es arriesgado porque SQLite siempre está en mitad de una escritura. Los patrones seguros son la API de backup online o una herramienta que gestione snapshots en caliente. Si vas con SQLite, trata los backups como un proyecto real desde el día uno, no como algo para el final.

Si eres un fundador solitario y prefieres no pensar en backups, Postgres gestionado o MySQL gestionado son las opciones obvias.

Cuándo rinde cada base de datos

Elige Postgres gestionado cuando:

  • Estás construyendo un SaaS multi-tenant y esperas añadir row-level security o aislamiento por tenant más adelante.
  • Quieres columnas JSON, full-text o queries geoespaciales sin montar un segundo servicio.
  • Prevés necesitar extensiones para analítica, vectores o series temporales.
  • Quieres el mayor catálogo de opciones gestionadas, tiers gratuitos y serverless.

Elige MySQL gestionado cuando:

  • Tu stack ya es sabor MySQL (WordPress, muchos CMS, Magento, código legacy).
  • Tienes tráfico read-heavy con joins sencillos y quieres una base de datos indulgente y predecible.
  • Quieres hacer joins entre tablas de bases de datos distintas, cosa que MySQL permite de fábrica y Postgres no sin la extensión de foreign data wrapper.
  • Tienes experiencia operativa concreta en MySQL y cero tiempo para aprender un dialecto nuevo.

Elige SQLite cuando:

  • Estás construyendo un producto single-user, single-tenant o local-first donde cada cliente tiene su propio archivo de base de datos.
  • Vas a distribuir un producto embebido, una app de escritorio o una herramienta CLI que necesita una base de datos real sin servidor.
  • Tu workload es read-heavy con escrituras en ráfagas o poco frecuentes.
  • Quieres cero infraestructura explícitamente y estás cómodo siendo dueño de backups, migraciones y replicación.

Flujo de decisión práctico

Si aún dudas, recorre esto paso a paso:

  1. ¿Estás construyendo un SaaS multi-tenant con escrituras concurrentes? Sí inclina hacia Postgres gestionado. No deja las tres abiertas.
  2. ¿Necesitarás queries JSON, full-text o row-level security en el primer año? Sí inclina hacia Postgres gestionado. No mantiene a MySQL gestionado en la pelea.
  3. ¿Tu stack ya está casado con MySQL? Sí inclina hacia MySQL gestionado. No deja a Postgres como valor por defecto.
  4. ¿Vas a distribuir un producto por usuario o por archivo de cliente? Sí inclina hacia SQLite. No descarta SQLite para un backend SaaS.
  5. ¿Quieres no volver a pensar en backups? Sí inclina hacia gestionado. No deja a SQLite en juego.

Si has dicho “sí” a uno y “no” al resto, ya tienes respuesta. Si estás en un punto medio, Postgres gestionado es el valor por defecto más seguro.

Próximos pasos concretos

  • Si elegiste Postgres gestionado: escoge un proveedor gestionado con tier gratuito generoso, pon un pooler de conexiones delante desde el día uno y activa los backups automatizados y el point-in-time recovery antes de escribir tu primera migración.
  • Si elegiste MySQL gestionado: el mismo playbook. Verifica los topes de almacenamiento y conexiones del tier gratuito y asegúrate de que los backups automatizados están activados por defecto.
  • Si elegiste SQLite: monta la API de backup online o una herramienta que gestione snapshots en caliente, escribe un simulacro de restauración y documenta tu ruta de migración a Postgres para el día en que tu producto supere al single-writer.

Preguntas frecuentes

¿Es SQLite seguro para producción? Para los workloads para los que fue diseñado, sí. Para un SaaS multi-tenant con muchos escritores concurrentes, no. Trata SQLite como una herramienta de especialista, no como una base de datos SaaS generalista.

¿Puedo empezar con SQLite y migrar a Postgres después? Puedes, pero te costará tiempo de ingeniería que preferirías invertir en el producto. Si hay una posibilidad real de que superes SQLite en menos de un año, empieza con Postgres gestionado y ahórrate la reescritura.

¿De verdad necesito un pooler de conexiones para Postgres? Si usas funciones serverless o cualquier patrón que abra muchas conexiones de corta vida, sí. Es uno de los gotchas más comunes para fundadores indie que se pasan a Postgres gestionado.

¿MySQL es más simple que Postgres? Históricamente MySQL se consideraba más fácil de empezar. Hoy, para la mayoría de workloads SaaS, ambos están bien documentados y ambos tienen opciones gestionadas maduras. Elige por tu stack y tus necesidades funcionales, no por una simplicidad percibida.

Fuentes