Una de las preguntas que más nos hacen sobre Payload es con qué base de datos funciona. La respuesta corta: con las más usadas, y se elige con un adaptador. Pero la elección importa más de lo que parece, porque cambia cómo despliegas, cómo migras y cuánto pagas.
Los adaptadores
Payload no trae una base de datos propia. Instalas el adaptador de la que quieras y lo pones en db dentro de la configuración:
Base de datos | Paquete | Notas |
|---|---|---|
MongoDB |
| Usa Mongoose. Documentos, sin esquema rígido. |
Postgres |
| Usa Drizzle. Relacional, migraciones SQL. |
Postgres en Vercel |
| Variante para el Postgres de Vercel. |
SQLite |
| Usa Drizzle. Un archivo local o un servidor libSQL como Turso. |
D1 de Cloudflare |
| SQLite de Cloudflare, para correr Payload en Workers. |
La lista cambia con las versiones, así que antes de decidir confirma los adaptadores vigentes en la documentación de Payload.
Cómo se siente cada una
MongoDB. Natural si tu equipo ya la usa y tus datos son anidados. No necesitas migraciones para cambiar un campo. A cambio, las relaciones entre colecciones son más débiles y consultar datos muy relacionados cuesta más.
Postgres. La opción más sólida para datos relacionados y mucha concurrencia. Tiene tablas, claves foráneas y todo el ecosistema de herramientas SQL. Lo que cambia: hay que manejar migraciones y tener un servidor de base de datos (propio o administrado).
SQLite. Una base en un archivo. En desarrollo es la más cómoda: sin instalar nada, se borra y se recrea. En producción solo hace falta que el archivo sea accesible, y ahí entra Turso.
D1. Es la SQLite de Cloudflare. Tiene sentido si ya despliegas Payload en Cloudflare Workers, porque la base se conecta como un binding. Fuera de ese caso, no hay razón para elegirla.
Migraciones y modo de desarrollo
Con las bases relacionales (Postgres y SQLite), Payload en desarrollo ajusta las tablas solo al cambiar tu esquema, y en producción se usan migraciones versionadas: payload migrate:create genera el SQL y payload migrate lo aplica. Con MongoDB no hay tablas que migrar. Cómo lo montamos con Turso, comando por comando, está en Payload CMS con Turso paso a paso.
Cómo elegir
- Sitio de contenido, blog, corporativo: SQLite/Turso o Postgres. Se escribe poco y se lee mucho; cualquiera aguanta.
- Aplicación con muchas escrituras a la vez (pedidos, reservas, sesiones): Postgres. SQLite admite un solo escritor a la vez.
- Tu equipo ya vive en MongoDB: MongoDB, sin complicarse.
- Todo en Cloudflare: D1.
- Quieres que local y producción sean lo más parecidos posible sin instalar nada: SQLite, con un archivo en local.
Qué elegimos nosotros y por qué
Para este sitio usamos SQLite en local y Turso en producción: contenido que se lee mucho, pocas escrituras, y el mismo adaptador en los dos entornos. No es una decisión universal. Si el proyecto fuera una tienda con pedidos concurrentes, iríamos a Postgres. La comparación completa del CMS está en Payload vs Strapi vs Directus, y el resto del stack, en así está construido codegea.com.
Escrito por
Derian Pinto
Founder & Full Stack Developer
Fundador de Codegea. Desarrolla sitios, tiendas y plataformas a medida, e integra y da soporte a Arc XP para medios.