# Qué bases de datos soporta Payload CMS y cuál elegir

> Payload CMS funciona con MongoDB, Postgres, SQLite y D1 de Cloudflare. Qué diferencia hay entre ellas y cómo elegir según tu proyecto.

URL: https://codegea.com/payload-cms-que-bases-de-datos-soporta
CMS · 2026-10-18 · Derian Pinto

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 | `@payloadcms/db-mongodb` | Usa Mongoose. Documentos, sin esquema rígido. |
| Postgres | `@payloadcms/db-postgres` | Usa Drizzle. Relacional, migraciones SQL. |
| Postgres en Vercel | `@payloadcms/db-vercel-postgres` | Variante para el Postgres de Vercel. |
| SQLite | `@payloadcms/db-sqlite` | Usa Drizzle. Un archivo local o un servidor libSQL como Turso. |
| D1 de Cloudflare | `@payloadcms/db-d1-sqlite` | 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](https://payloadcms.com/docs/database/overview).

## 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](/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](/payload-cms-vs-strapi-vs-directus-en-2026), y el resto del stack, en [así está construido codegea.com](/asi-esta-construido-codegea-nextjs-payload-turso-r2).