Sanity.io fue fundada en Oslo en 2014, y en 2025 acabó absorbida por Contentful. Pero jamás envió un CMS. Envió una base de datos JSON, un lenguaje de consultas que nadie fuera de su ecosistema conoce, y un editor React open source que esperan que reconstruyas
Los equipos que triunfan con Sanity son los que dejan de preguntar "¿qué pinta el dashboard?" y empiezan a preguntar "¿cuál es mi esquema de contenido?".
El resto fracasa. No por culpa de Sanity. Por culpa de su propio marco mental.
La sabiduría convencional dice: "un CMS es donde los editores escriben blogs, y eliges uno comparando dashboards, plugins y editores WYSIWYG". Eso es erróneo a tres niveles cuando hablamos de Sanity.
Primero: Sanity no tiene páginas. El contenido es JSON definido por esquema. Comparar dashboards es comparar la decoración cuando lo que eliges es la capa de datos.
Segundo: todo el mundo asume que headless = "sin edición visual". Falso. La colaboración en tiempo real y Visual Editing dan a los editores previews en vivo.
Tercero: la mayoría asume que las consultas necesitan GraphQL o REST. Sanity responde con GROQ, un lenguaje completo que supera a GraphQL típico para contenido relacional. Elegir Sanity significa comprometerte con un lenguaje que la mayoría de desarrolladores jamás ha oído nombrar.
El take más contracorriente: la mayor debilidad de Sanity es también su mayor fortaleza. No hay producto hasta que escribes código.
---
El Problema: Estás Comparando CMS Cuando Deberías Elegir una Capa de Datos
WordPress, Drupal, incluso Strapi: organizan el contenido alrededor de páginas o documentos con campos fijos.
Sanity lo organiza alrededor de un esquema que escribes en TypeScript. Arrays, objetos, referencias y bloques de portable text. La misma entidad puede renderizarse como página web, tarjeta móvil, layout de impresión o respuesta de API sin duplicación.
Pero eso significa que los stakeholders no técnicos necesitan que les expliques el esquema antes de siquiera ver un editor.
Ahí está el primer choque. Tu cliente quiere escribir un artículo. Tú le enseñas un fichero de TypeScript.
Y el segundo choque ocurre un mes después, cuando intentas la integración con herramientas esperando un endpoint REST y descubres GROQ.
❌ El enfoque equivocado: Buscas el mejor "CMS headless" comparando dashboards, WYSIWYG y plugins. Esperas un giro que te dé el panel bonito.
✅ El enfoque correcto: Asumes que estás eligiendo una capa de datos. El esquema es un contrato de programación, no una pantalla de ajustes. Y ese contrato vive en git.
El tercer choque es el más silencioso: la adquisición por parte de Contentful en 2025. Dos de los nombres más grandes del headless content se fusionaron por lógica de infraestructura y consolidación, no por listas de features.
Para ti, como desarrollador, es una señal clara: elige tu stack por modelado de datos y diseño de API, no por el roadmap del vendor actual. Porque el mapa de vendors se mueve debajo de tus pies.
---
La Evidencia: Lo que Sanity Realmente Despliega
Desmontemos la arquitectura. Sanity es, arquitectónicamente, una base de datos de contenido hospedada — el famoso content lake. El contenido se almacena como documentos JSON, no como páginas renderizadas. No existe una entidad "página" en el modelo de datos.
Esa pieza cambia todo.
El Studio es open source bajo licencia MIT, y es una aplicación React configurable. La interfaz de edición es código que tus equipos pueden extender o reemplazar. Se configura vía sanity.config.ts, no vía un panel de administración.
Y GROQ — Graph-Relational Object Queries — es el motor relacional. Proyecta, filtra, atraviesa arrays y desreferencia referencias con el operador ->. Sin GraphQL. Sin fragamentos. Sin round-trips REST.
Se acabó el comparar paneles. Esto es lo que eliges: una configuración de TypeScript que define cómo se modelo y edita tu contenido.
La evidencia está en el modelo de datos, no en el marketing.
---
El Análisis: Por Qué esto Importa Ahora, en 2026
La consolidación del mercado confirma el papel de Sanity. La adquisición por Contentful en 2025 reframe por completo la categoría. Dos gigantes del headless content se fusionaron y la lógica fue de infraestructura y consolidación: no listas de features.
Para ti, desarrollador, hay una lección práctica y urgente: tu contenido deja de ser documentos de un vendor y se convierte en datos versionados en git. El esquema vive en tu repositorio, se revisa en pull requests, se migra con commits, no con clics en un panel.
Eso es lo que ningún CMS administrado te ha podido dar jamás.
Y la edición visual disuelve la vieja línea entre headless y legacy. El Presentation tool y la colaboración en tiempo real dan a los editores previews en vivo sobre el frontend real. Lo que los críticos del headless siempre dijeron imposible — editar con contexto visual — es ahora el default.
El resultado práctico: "headless" ya no significa "a ciegas". El factor decisivo entre Sanity y un CMS legacy ya no es el preview. Es si quieres tu modelo de contenido versionado en git o atrapado en una base de datos opaca.
---
El Framework: El Patrón del Esquema Como Contrato
Paso 1: Scaffold y Acepta el Studio por Defecto
Acepta el setup por defecto. Crearás una app Next.js o Remix con el Studio integrado. No te preocupes por personalizar aún. La personalización viene después, cuando el esquema esté estable.
Paso 2: Modela Contenido Como Código Primero
Resiste la tentación de empezar por la UI. Define cada tipo — post, autor, producto — como un objeto TypeScript con campos, validación y referencias.
Este fichero es tu contrato. Vive en git. Se revisa en PR. Se versiona.
Paso 3: Consulta con GROQ a través de @sanity/client
Versiona tus queries en un único fichero. Usa el plugin Vision en Studio para iterar contra datos reales.
El operador `->` desreferencia referencias inline. Lo que en GraphQL serían múltiples fragments, en GROQ es una línea.
Paso 4: Conecta a tu Frontend
Sanity sirve desde CDN por defecto. El caching es parte de la capa de datos, no un plugin.
Paso 5: Real-time en vez de Rebuilds Estáticos
Activa el draft mode o el preview. Usa client.listen() o el Presentation tool para actualizaciones de contenido instantáneas, en vez de rebuilds on-publish.
Paso 6: Extiende el Studio para tus Workflows Reales
El editor es una app React que posees. Añade inputs custom, validación específica y plugins. Después itera sobre el esquema sabiendo que las migraciones son aditivas, no destructivas.
El nombre de este patrón: El Patrón del Esquema Como Contrato. El esquema no es configuración. Es el contrato firmado entre editores, frontend y API. Todo lo demás — Studio, queries, previews — desciende de él.
---
Las Objeciones que Me Harías (y sus Respuestas)
"¿Por qué añadir GROQ al stack cuando ya conozco GraphQL? ¿No eleva la curva de aprendizaje y me encierra en Sanity?"
GROQ se aprende en una tarde. Viene con el client oficial. Y el contrato esquema-as-code reduce el riesgo de lock-in comparado con esquemas opacos de base de datos. La concesión honesta: el ecosistema de tooling es menor que el de GraphQL.
"El contenido JSON estructurado significa que no hay integridad relacional real — las referencias son strings que pueden quedar huérfanas."
El tipo reference de Sanity incluye reglas de validación. El trade-off: flexibilidad y evolución sin migraciones destructivas contra garantías de foreign keys estrictas. Si tu equipo necesita constraints ACID duros, reconsidera si un CMS es la herramienta correcta en absoluto.
"Es SaaS hospedado — ¿y si el servicio o el vendor fusionado cambia de rumbo tras la adquisición?"
El Studio es open source MIT. La API y la especificación GROQ son públicas. Puedes exportar y hacer backup del contenido vía la API. Mitigación real. Pero sé honesto: el content lake es un servicio administrado. Si necesitas self-hosting extremo, valora eso antes de comprometerte.
---
Resumen y Hacia Delante
El error colectivo es tratar Sanity como un WordPress sin interfaz. Lo que es: una base de datos de contenido donde el esquema es un contrato TypeScript versionado en git, consultada con GROQ, administrada por un editor React open source.
Los take-aways:
- El esquema es el producto. Todo lo demás desciende.
- GROQ reemplaza lo que a GraphQL le costaría fragments y round-trips.
- El editor es código que posees, no un dashboard alquilado.
- El contenido versionado en git es la razón real de elegir Sanity.
La frase que me repito cada vez que un cliente me enseña el "CMS": elige tu stack por el modelo de datos, no por la lista de features del vendor actual. El mapa de vendors se moverá. Tu esquema, versionado en git, permanece.
Artículos relacionados
- Sanity.io Headless CMS Tutorial: El CMS que Construyes Tú Mismo (No al Revés)
- Sanity.io Headless CMS Tutorial: El CMS que Construyes Tú Mismo (No al Revés)
- Sanity.io Headless CMS Tutorial: No es un CMS. Es una Infraestructura de Contenido en Tiempo Real
- Sanity.io Headless CMS Tutorial: El CMS que Construyes Tú Mismo (No al Revés)
- Sanity.io Headless CMS Tutorial 2026: No es un CMS. Es una Base de Datos de Contenido en Tiempo Real
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
