¿Qué es un CMS basado en Git? La forma más práctica de gestionar contenido “sin base de datos”

Al montar un sitio web, tarde o temprano aparecen dudas como:

“Hay que actualizar blog/documentación/landings a menudo, pero no queremos mantener una base de datos.”
“Queremos saber quién cambió qué cada vez que cambia el contenido.”
“Necesitamos un flujo donde el contenido pase por revisión antes de publicarse.”

Una de las respuestas más limpias es un CMS basado en Git (Git-based CMS). En una frase:

Un CMS que guarda el contenido en «archivos» (Markdown/JSON/YAML) en lugar de en una base de datos, y registra cada cambio como un commit (o PR) de Git.

Conceptos clave de un CMS basado en Git

1) El contenido son “archivos”

Los CMS tradicionales (p. ej. WordPress) guardan el contenido en una base de datos. Un CMS basado en Git suele guardarlo así:

content/posts/hello-world.md
content/docs/getting-started.md
data/products.json

Es decir, el repositorio es el almacén de datos del CMS.

2) Los cambios se registran como “commits”

Cuando editas contenido, el CMS crea un commit en Git. Con eso obtienes de forma automática:

Quién lo cambió (autor)
Cuándo (marca de tiempo)
Qué cambió (diff)
Cómo deshacerlo (revert)

El “historial de cambios del contenido” viene casi gratis gracias a Git.

3) El despliegue se hace con un “build”

La mayoría de CMS basados en Git encajan bien con sitios estáticos (SSG) o híbridos (Next.js, Astro, etc.).

El flujo suele ser:

Editar en el CMS → se crea commit/PR en Git
Se ejecuta CI/CD → se construye el sitio
Se despliegan los estáticos (Vercel, Netlify, Cloudflare Pages, etc.)

¿Por qué un CMS basado en Git?

Menor coste operativo (menos DB/servidor)

Backup, migración y parches de seguridad de la base de datos se reducen o desaparecen.
Los “datos” son solo archivos; en el peor caso, con el repo de Git basta para recuperar.

Colaboración y revisión naturales

Si trabajas con PRs, el contenido se puede revisar como el código:

Borrador → abrir PR
Revisión (corrección/verificación) → aprobar
Merge → despliegue automático

Cuanto más equipo de contenido tengas, más rentable es esta estructura.

Buen rendimiento

Los sitios estáticos son rápidos por naturaleza:

Amigables con caché y CDN
Menor coste de servidor

Inconvenientes (donde muchos fallan)

1) No encaja con apps con muchas escrituras

Comentarios, likes, pedidos, carritos: apps donde el usuario escribe datos con frecuencia no encajan bien con un CMS basado en Git.

Los commits se disparan
Aumentan las ediciones simultáneas y los conflictos
Muchos builds implican más coste y tiempo de despliegue

2) Búsqueda, filtros y datos relacionales complejos son más difíciles

“Listado por etiqueta”, “ordenar por popularidad”, “joins relacionales” son lo que mejor hace una base de datos.

En un CMS basado en Git también se puede, pero suele hacerse así:

Generar JSON de índice en el build
Pre-generar páginas de listados/etiquetas
Conectar un motor de búsqueda (p. ej. Algolia)

Es decir, el rendimiento puede ser muy bueno, pero diseño e implementación se complican.

3) El tiempo de build crece con el tamaño del contenido

Con miles (o decenas de miles) de artículos, el tiempo de build y despliegue deja de ser despreciable. Ahí hace falta una estrategia híbrida (p. ej. ISR, builds incrementales).

¿Qué tipo de sitio encaja mejor?

Un CMS basado en Git encaja especialmente con:

Páginas corporativas y de marketing / landings
Blogs y newsrooms
Documentación de producto o servicio
Portfolios y casos de estudio
Catálogos estáticos (precios, menús, cursos)

Para lo siguiente suele ser mejor un híbrido (CMS basado en Git solo para contenido, otro almacenamiento para el resto):

Miembros, login, permisos
Comentarios, reseñas, foros
Pagos, pedidos, inventario

Tipos de CMS basado en Git (por categoría)

A) “Añadir /admin al sitio”

Se añade una interfaz de CMS al sitio estático; las ediciones crean commits en el repo.
Ventajas: Configuración simple, buena combinación con SSG.
Inconvenientes: La UX de edición varía por proyecto; puede haber límites según la configuración.

B) “Integrado en el framework”

Funcionalidad de CMS integrada en Next.js, Astro, etc.
Ventajas: Buena experiencia de desarrollo, fácil de personalizar.
Inconvenientes: Configuración inicial puede ser más pesada que A.

C) “Servicio comercial / alojado”

Suele ofrecer mejor experiencia para editores no desarrolladores.
Colaboración, permisos, vista previa, etc.
Inconvenientes: Coste y posible dependencia del proveedor.

Arquitectura práctica (patrón recomendado)

“Contenido en Git, datos dinámicos aparte”

Una configuración realista es:

Artículos/documentación/páginas: CMS basado en Git (archivos + commits)
Likes, contadores, configuración sencilla: Almacenamiento serverless (p. ej. KV)
Usuarios, pagos, transacciones: Una base de datos adecuada (SQLite, Postgres, etc.)

Es decir, usar un CMS basado en Git solo para el contenido y mantener los datos de servicio en el almacén adecuado.

Lista de adopción (no la saltes)

¿Quién edita?
Si muchos editores no son desarrolladores, la UI, permisos y vista previa importan mucho.
¿Hace falta revisión?
Si quieres revisión basada en PRs, un CMS basado en Git encaja muy bien.
¿Con qué frecuencia se actualiza?
Si el contenido cambia decenas de veces al día, piensa en coste de build y despliegue.
¿Son centrales la búsqueda, filtros y listados?
Planifica indexación en el build o un servicio de búsqueda externo.
¿Puede crecer mucho el volumen de contenido?
Piensa con antelación en ISR, caché y optimización del build.

Conclusión: “Funcionar sin DB” suele significar un CMS basado en Git

Un CMS basado en Git encaja muy bien con el objetivo de “gestionar contenido sin base de datos”:

Historial de cambios, colaboración, revisión: lo resuelve Git
Despliegue y rendimiento: build estático + CDN
Coste operativo: bajo

Pero meter también todos los datos de servicio en Git es un error. Usa el CMS basado en Git solo para el contenido; el resto en KV, SQLite o una base de datos adecuada.