Elegir un CMS para un sitio de marketing en Next.js: headless o basado en base de datos

Elige una base de datos, como Supabase, cuando un desarrollador controla cada publicación y el sitio se mantiene en un puñado de páginas. Elige un CMS headless cuando los editores necesiten publicar sin depender de un desarrollador, o cuando el mismo contenido deba llegar a más de un canal. Según la actualización de junio de 2026 de la documentación de Next.js, ambos enfoques terminan sirviéndose de la misma forma en producción, como páginas prerenderizadas que se revalidan por temporizador. La diferencia real está en quién edita el contenido y cómo, no en la velocidad bruta.

Qué es cada uno y por qué importa

Un CMS headless es una plataforma solo de backend. Almacena, modela y gestiona contenido, y luego lo entrega mediante una API REST o GraphQL en lugar de renderizar su propio frontend, como describe la visión general de Vercel. Un sitio en Next.js consume esa API en tiempo de build o de solicitud y renderiza la página. El CMS trae su propia interfaz de edición, su propio modelo de permisos y sus propios tipos de contenido, separados del código base.

El contenido basado en base de datos prescinde de ese sistema separado. El contenido vive en la misma base de datos Postgres que ya usa el resto de la aplicación, normalmente Supabase, y un Server Component de Next.js la consulta directamente con la librería cliente estándar. No hay un segundo proveedor ni una capa de API que mantener más allá de los endpoints que la propia base de datos genera.

La elección importa desde el principio porque cambiarla más adelante implica reescribir la capa de obtención de contenido y volver a capacitar a quien publica. Un CMS headless justifica su costo cuando el contenido necesita llegar a una app móvil, al sitio de un socio o a un kiosco además de las páginas de marketing, ya que el mismo contenido estructurado sirve a cada canal sin duplicarlo. Ese costo se recupera de una segunda forma: en el momento en que alguien del equipo de marketing sin conocimientos técnicos necesita publicar una página sin abrir un pull request. La propia guía de Vercel para elegir uno plantea la decisión en torno al flujo editorial, las necesidades de modelado de contenido y el volumen de publicación, no en torno a la compatibilidad con el framework, ya que ambos modelos funcionan bien con Next.js.

Cómo funciona en la práctica

Caché y frescura

Ningún modelo cambia la forma en que Next.js almacena en caché una página. Definir export const revalidate = 3600 en una ruta le indica a Next.js que sirva la versión en caché durante hasta una hora y luego la regenere en segundo plano en la siguiente solicitud, sin tiempo de inactividad para el visitante mientras tanto, según la guía de Incremental Static Regeneration de Next.js. Para una consulta directa a la base de datos en lugar de una llamada fetch, la misma guía recomienda envolver la consulta en unstable_cache con un intervalo de revalidate y etiquetas de caché, de modo que una página respaldada por Supabase obtenga el mismo comportamiento stale-while-revalidate que una respaldada por un CMS. Cómo funciona ese mecanismo de caché de principio a fin explica con más detalle la ventana de revalidación y la regeneración en segundo plano.

Publicar un cambio

Con un CMS headless, un editor guarda un cambio y el CMS dispara un webhook que llama a revalidatePath o revalidateTag, actualizando la página en caché en la siguiente solicitud. Con un sitio basado en base de datos, una Server Action escribe la fila directamente y llama a esa misma función, sin necesidad de un salto por webhook. El trabajo de invalidación es equivalente en ambos casos; un CMS headless simplemente añade un salto de red entre el guardado y la revalidación.

Control de acceso

Un CMS headless trae sus propios roles de editor y permisos de contenido de fábrica. Un sitio basado en base de datos depende de políticas de Row Level Security a nivel de Postgres para cumplir la misma función, restringiendo qué filas puede leer o escribir una clave o un usuario autenticado determinado. Ambos son control de acceso real. La diferencia está en si ese control vive en el panel de administración de un proveedor o en políticas que el equipo escribe y posee.

Ventajas, desventajas y casos límite

Costo

Las plataformas de CMS headless conllevan una factura recurrente. Los precios van desde unos 99 USD al mes en el extremo más bajo hasta unos 300 USD al mes en plataformas orientadas a empresas, o un modelo por asiento cercano a 15 USD por asiento al mes, según la comparativa de CMS headless de Vercel. Un sitio basado en base de datos evita esa línea de gasto, pero si los editores necesitan una forma sencilla de publicar, alguien igual tiene que construir y mantener una interfaz de administración ligera sobre la base de datos. Ese es su propio costo continuo, solo que distinto.

Independencia editorial frente a propiedad del desarrollador

La mayoría de los sitios de marketing que construye Kallos Labs son un puñado de páginas, mantenidas por el mismo equipo que las construyó. Para ese tipo de sitio, un CMS headless es una sobrecarga que el proyecto todavía no ha recuperado, ya que el desarrollador que publica el contenido ya está en el código base. El cálculo cambia en el momento en que un responsable de marketing necesita modificar un texto, añadir una página o lanzar una campaña sin esperar tiempo de ingeniería.

Reutilización multicanal

Si el mismo artículo, descripción de producto o pregunta frecuente necesita llegar a una app nativa o al sitio de un socio además de las páginas de marketing, el contenido estructurado de un CMS headless evita mantener esa copia en dos o tres lugares. Una tabla de base de datos limitada al esquema de un solo sitio no se generaliza de la misma forma sin trabajo adicional.

Restricciones técnicas en ambos casos

Incremental Static Regeneration requiere el runtime de Node.js y no es compatible con una exportación estática, una restricción que la documentación de Next.js señala con claridad, así que la elección de hosting importa sin importar qué modelo de contenido se use. Una lista de verificación de auditoría técnica de SEO para sitios en Next.js cubre los problemas de caché e indexación que aparecen bajo cualquiera de los dos enfoques. Cuando un cliente le pregunta a Kallos Labs cuál le conviene, la respuesta sale del proceso de descubrimiento, en concreto de quién va a publicar y con qué frecuencia, no de una elección de herramienta por defecto. El servicio de desarrollo web delimita esa decisión antes de escribir una sola línea de código.

Preguntas frecuentes

¿Es un CMS headless más rápido que un sitio en Next.js basado en base de datos?

No, por defecto no. Ambos modelos terminan como páginas estáticas o en caché con ISR servidas desde la misma CDN, así que la velocidad depende de la estrategia de caché y del intervalo de revalidación, no de qué sistema almacena el contenido.

¿Puede un equipo de marketing editar contenido sin un CMS headless?

Sí, si existe una interfaz de administración o una herramienta interna ligera frente a la base de datos. Sin eso, cada cambio de contenido pasa por un desarrollador, que es el costo real de prescindir de un CMS.

¿Cuenta Supabase como un CMS headless?

No. Supabase es una base de datos Postgres alojada con Row Level Security y APIs autogeneradas, no una capa de modelado de contenido o editorial. Un equipo puede construir una interfaz de administración ligera encima, pero esa interfaz es trabajo a medida que el propio equipo posee y mantiene.

¿Cuándo tiene sentido migrar de un blog basado en base de datos a un CMS headless?

Tiene sentido en cuanto los editores sin conocimientos técnicos necesitan acceso directo de publicación, en cuanto el mismo contenido debe llegar a un segundo canal, o en cuanto el modelo de contenido supera a un puñado de tablas y necesita versionado, vistas previas y flujos de localización que un CMS ya trae incorporados.

Conclusión

La decisión se reduce a quién publica y a cuántos canales sirve el contenido. Un sitio controlado por desarrolladores con un puñado de páginas funciona bien solo con una base de datos y el ISR de Next.js. Un sitio donde los editores necesitan independencia, o donde el contenido debe llegar más allá de las páginas de marketing, recupera el costo de un CMS headless. En cualquier caso, la misma capa de caché mantiene las páginas rápidas por debajo: los intervalos de revalidación se encargan del trabajo rutinario, y la invalidación bajo demanda se encarga del resto.