Bases de datos con plan gratuito: qué mirar

Al elegir una base de datos con plan gratuito, el tamaño en gigabytes es casi siempre el dato menos importante. Lo que decide si el proyecto va a funcionar dentro de seis meses es otra cosa: si la base de datos se pausa cuando nadie la usa, cuántos proyectos te dejan tener, cuántas conexiones simultáneas aguanta y cómo de fácil es llevarte los datos a otro sitio.

Ningún proyecto pequeño llena el almacenamiento gratuito de un proveedor moderno. Lo que sí pasa, y pasa pronto, es lo otro.

La pausa por inactividad es el factor número uno

Muchos niveles gratuitos suspenden la base de datos cuando lleva un tiempo sin recibir consultas y la despiertan con la siguiente. Para un proyecto en desarrollo es perfecto: no gastas recursos mientras no trabajas. Para una demo que enseñas a clientes o un proyecto con visitas esporádicas, es exactamente el peor comportamiento posible, porque la primera petición después de la pausa es la que va a ver alguien.

Antes de decidir, contesta dos preguntas: ¿cuánto tarda en dormirse? y ¿cuánto tarda en despertar? Un despertar de un segundo es un detalle; uno de treinta es un producto distinto.

Si tu proyecto tiene tráfico irregular pero real, prioriza un proveedor que no pause, aunque te dé menos almacenamiento.

Proyectos y ramas: el límite que se alcanza primero

El segundo tropiezo habitual. Es normal necesitar al menos tres bases de datos por proyecto —desarrollo, pruebas y producción—, y muchos planes gratuitos dan una o dos en total, para todo.

Aquí es donde cambia bastante el panorama según el proveedor. Los que ofrecen ramas de base de datos —copias baratas del esquema para trabajar en paralelo, al estilo de Neon— resuelven el problema de otra forma: en vez de contar proyectos, cuentan ramas, y para un flujo de trabajo con pull requests eso encaja mucho mejor.

Comprueba también si el entorno de pruebas cuenta contra el límite. Suele contar.

Conexiones simultáneas, no consultas

Un límite que sorprende a quien viene de un servidor propio. Postgres reserva memoria por conexión, así que los planes gratuitos limitan cuántas puede haber abiertas a la vez. Con un servidor tradicional y su pool, da igual. Con funciones sin servidor —que es donde acaba casi todo hoy— cada invocación tiende a abrir la suya, y el límite se alcanza con muy poco tráfico.

La solución es un pooler de conexiones, y lo importante es saber si el proveedor lo incluye o si te toca montarlo. Proveedores como Supabase o Neon lo dan de serie; con otros, es trabajo tuyo.

Si vas a desplegar en funciones sin servidor o en el borde, esto pesa más que el almacenamiento.

Qué tipo de base de datos necesitas de verdad

Merece la pena parar un momento aquí, porque elegir mal de familia cuesta mucho más que elegir mal de proveedor:

• Relacional (Postgres, MySQL). El valor por defecto sensato. Si dudas, esto. Casi todo el mundo lo entiende, la documentación es infinita y migrar entre proveedores de Postgres es realista.
• Documental (MongoDB). Cómodo cuando los datos son irregulares y todavía no sabes bien la forma que van a tener. MongoDB Atlas tiene nivel gratuito permanente.
• Clave-valor / caché (Redis). No es la base de datos principal: es la capa de al lado para sesiones, colas y límites de tasa. Upstash cobra por petición, lo que encaja bien con proyectos pequeños.
• SQLite distribuido. Interesante para lecturas rápidas cerca del usuario, con Turso como opción con plan gratuito. Menos maduro para escrituras intensas.
• Vectorial. Solo si estás haciendo búsqueda semántica o recuperación para modelos de lenguaje. Qdrant tiene nivel gratuito. Si no, no compliques.

La lista completa, con los límites de cada uno, está en datos y backend.

Copias de seguridad y salida

Dos preguntas y las dos incómodas:

¿El plan gratuito incluye copias de seguridad automáticas? Muchas veces no, o solo de los últimos días. Si tu proyecto tiene datos de personas, esto no es opcional: monta un volcado periódico tú mismo aunque el proveedor prometa algo.

¿Puedes sacar los datos sin pedir permiso? Con Postgres o MySQL la respuesta es sí por definición: pg_dump y ya. Con bases de datos propietarias, depende, y ahí es donde se decide si estás eligiendo un proveedor o firmando una hipoteca. Es el mismo criterio que aplicamos en los límites del plan gratuito que nadie lee.

Un método corto para decidir

Cuatro pasos y en este orden:

1. Elige familia según la forma de tus datos, no según el proveedor de moda.
2. Descarta por pausa si tu proyecto va a recibir visitas reales, aunque sean pocas.
3. Comprueba proyectos y conexiones contra cómo vas a desplegar de verdad.
4. Prueba la exportación el primer día, con la base de datos vacía. Cuesta cinco minutos entonces y es imposible después.

Y una nota que vale para todo el directorio: los planes gratuitos cambian sin avisar. La página oficial de precios de cada proveedor manda sobre cualquier comparativa, esta incluida.

Preguntas frecuentes

¿Cuál es la mejor base de datos gratuita para empezar un proyecto? Para la mayoría de proyectos, Postgres gestionado. Es el estándar más portable, la documentación es abundante y si el proveedor deja de convenirte puedes migrar a otro Postgres sin reescribir la aplicación. La elección entre proveedores concretos depende más de la pausa por inactividad y del número de proyectos que de sus prestaciones.

¿Puedo usar una base de datos gratuita en producción? Sí, si el proyecto tolera lo que el plan gratuito no garantiza: sin compromiso de disponibilidad, con posible pausa y con copias de seguridad limitadas. Para un proyecto interno, una demo o un producto que está validando la idea, es perfectamente razonable. Para algo con clientes que pagan, no.

¿Qué pasa cuando supero el almacenamiento gratuito? Depende del proveedor: algunos bloquean las escrituras y dejan leer, otros suspenden el proyecto y otros cobran el exceso. Es la pregunta que hay que hacerse antes de que ocurra, porque las tres consecuencias son muy distintas.

¿Necesito una base de datos vectorial para trabajar con IA? No siempre. Postgres con la extensión pgvector cubre bien la búsqueda semántica de proyectos pequeños y medianos, y te ahorra un servicio más que mantener. Una base de datos vectorial dedicada se justifica cuando el volumen o la latencia dejan de encajar.

¿Es mejor auto-alojar la base de datos? Auto-alojar quita el límite del plan gratuito y añade el trabajo de mantenerlo: actualizaciones, copias, seguridad y las llamadas de madrugada. Para un proyecto en solitario suele salir a cuenta el servicio gestionado hasta que el gasto sea significativo. Lo que sí conviene es elegir algo que se pueda auto-alojar el día que haga falta.