Por qué dejé Hygraph por Sanity

Algunas migraciones se posponen porque todo funciona. Mi sitio estaba operativo. Los artículos se publicaban en varios idiomas, el pódcast ⌘+P tenía sus feeds RSS y ⌘+F tenía su página de inicio. Hygraph cumplía su función.

Y, sin embargo, ya está hecho: clementsauvage.me, cmdf.io y el pódcast ⌘+P ya funcionan con Sanity en producción. Un proyecto, un modelo de contenido y siete configuraciones regionales.

Este no es un artículo que diga «Hygraph es malo, Sanity es bueno». Hygraph me ha dado buen servicio y sigue siendo una opción excelente para algunos equipos. Esta es la historia de unas necesidades cambiantes, con dos desencadenantes muy concretos —el coste y la IA—, y una reflexión más amplia sobre cómo debería un fundador elegir (y abandonar) una herramienta SaaS en 2026.

---

El punto de partida: un stack que funcionaba

Para contextualizar, esto es lo que utilizaba:

• Hygraph como CMS headless, nativo de GraphQL
• Next.js 16 (App Router, Turbopack), Tailwind v4
• Apollo Client para comunicarse con la API GraphQL
• next-intl para gestionar siete configuraciones regionales
• Clever Cloud Cellar (S3) detrás de Cloudflare para parte de los archivos y Mux para el vídeo

Nada exótico. Un stack moderno y limpio que todavía recomendaba a mis clientes hace unos meses.

El problema no era un error. Era una trayectoria: más idiomas, más contenido, más sitios y una forma de trabajar que se orientaba hacia los agentes de IA. A cada paso, Hygraph me costaba un poco más, ya fuera en dinero o en fricción.

Mi antiguo editor de Hygraph: los títulos y subtítulos en francés e inglés de «La receta para una gran aplicación de iOS», en la misma entrada. Captura de pantalla de mi proyecto, octubre de 2026.

---

Desencadenante n.º 1: el coste y, sobre todo, el coste de los idiomas

Siete configuraciones regionales en una tabla de precios pensada para dos o tres

Esto fue lo que lo inició todo. Publico como mínimo en francés e inglés, y mi front end admite siete configuraciones regionales. En Hygraph, la localización es un recurso cuyo precio depende del plan:

• el plan Hobby (gratuito) incluye 2 configuraciones regionales;
• el plan Growth parte de 199 $/mes e incluye 3 configuraciones regionales;
• a partir de ahí, entras en el terreno de los complementos y de Enterprise, cuyo precio se facilita previa solicitud (hasta 80 configuraciones regionales).

Para un creador independiente o una pequeña empresa que quiera que su contenido pueda leerse en varios idiomas, eso es un muro. El contenido multilingüe no es un lujo reservado a las empresas de la lista Fortune 500: forma parte del día a día de cualquiera que cree productos en Europa. Que se cobre como una opción prémium me parece un planteamiento al revés.

Las configuraciones regionales de mi proyecto de Hygraph: francés como idioma predeterminado, inglés y el límite del plan alcanzado con estos dos idiomas. Captura de pantalla de mi proyecto, octubre de 2026.

El salto al plan de pago

Segundo escalón: pasar del plan gratuito al de pago. Hobby es generoso en algunos aspectos, pero solo ofrece un entorno. En cuanto quieres un entorno de staging real para probar un cambio de esquema sin romper producción, necesitas el siguiente plan. Pasar de 0 $ a 199 $/mes de golpe por algo tan básico como un entorno de preproducción deja de tener sentido para un sitio personal y dos proyectos comunitarios.

Cuotas de la API y tráfico de recursos

Tercera fuente de fricción, más insidiosa: las cuotas.

• 500.000 operaciones de API al mes en Hobby y 1 millón en Growth. Parece mucho hasta que lo multiplicas por las configuraciones regionales, las páginas generadas, los feeds RSS del pódcast que se regeneran de forma programada y las compilaciones de vista previa.
• 100 GB de tráfico de recursos en Hobby. Las portadas del pódcast y los elementos visuales de los artículos y eventos de ⌘+F van sumando.

Ninguno de estos límites es desorbitado por sí solo. En conjunto, repartidos entre tres sitios que habrían sido tres proyectos de Hygraph, se traducen en una factura que crece más rápido que la audiencia.

Qué cambia Sanity en este aspecto

Sanity funciona de otra manera:

• Precio — Hygraph Hobby: 0 $; Sanity Free: 0 $.
• Configuraciones regionales — Hygraph Hobby: 2; Sanity Free: sin límite en el número*.
• Puestos — Hygraph Hobby: 3; Sanity Free: 20.
• Entornos / conjuntos de datos — Hygraph Hobby: 1; Sanity Free: 2 (producción + staging).
• Solicitudes de API — Hygraph Hobby: 500.000 operaciones/mes; Sanity Free: 1 millón de solicitudes a la CDN + 250.000 solicitudes de API/mes.
• Recursos — Hygraph Hobby: 100 GB de tráfico; Sanity Free: 100 GB de almacenamiento + 100 GB de ancho de banda.

* Sanity no cuenta los idiomas, sino los «atributos únicos» por conjunto de datos (2.000 en Free y 10.000 en Growth). Con la localización a nivel de campo, cada idioma multiplica las rutas de atributos, así que ese es el límite que debes vigilar. Más información al respecto a continuación.

Precios consultados a finales de septiembre de 2026 en las páginas oficiales de Hygraph y Sanity. Cambian a menudo, así que compruébalos antes de decidirte.

Y cuando Free no es suficiente, el plan Growth de Sanity cuesta 15 $ por puesto al mes. Para un equipo de dos o tres personas, está muy por debajo del precio inicial de 199 $ de Hygraph Growth, con todos los idiomas incluidos.

---

Desencadenante n.º 2: la IA, o el CMS como herramienta para agentes

El coste hizo que buscara alternativas. La IA hizo que eligiera Sanity.

Mi forma de escribir ha cambiado. Cada vez redacto, traduzco, reviso y publico más con agentes —Claude, Codex— que trabajan con mi código y mi contenido. La pregunta ya no es «¿es agradable la interfaz de edición?», sino: ¿puede mi agente entender y manipular mi contenido tan bien como yo?

Sanity lleva ventaja en ese aspecto.

El servidor MCP: escribir en el CMS desde Claude o Codex

Sanity ofrece un servidor MCP oficial, alojado en https://mcp.sanity.io. Un solo comando basta para conectarlo:

npx sanity@latest mcp configure

Detecta tu editor (Claude Code, Cursor, VS Code) y configura la conexión utilizando tus credenciales de la CLI. Para Claude Code, también puedes añadirlo manualmente:

claude mcp add Sanity -t http https://mcp.sanity.io --scope user

A partir de ahí, el agente puede consultar contenido en GROQ con pleno conocimiento del esquema, crear, modificar, publicar y retirar documentos, gestionar versiones, subir recursos desde una URL y desplegar el esquema.

En la práctica, mi flujo de trabajo ahora es así: trabajo en un artículo con el agente, lo reviso y el agente crea el borrador directamente en Sanity con los campos, las etiquetas y las traducciones correctos. Lo reviso en Studio y lo publico. Se acabó copiar y pegar entre un editor de Markdown y una interfaz web.

Traducir a siete idiomas

Con siete configuraciones regionales, la traducción no es un detalle: supone la mitad del trabajo editorial. Entre el servidor MCP y las funciones de IA integradas de Sanity (AI Assist, Agent Actions), puedo generar una primera versión para cada idioma y hacer que después se revise. La IA se encarga del trabajo pesado; una persona conserva la última palabra, especialmente en lo relativo al tono y los términos técnicos.

Mi Sanity Studio: la lista de artículos de clementsauvage.me, con títulos en francés e inglés en el mismo documento. Captura de pantalla de mi proyecto, octubre de 2026.

Esquemas que la IA puede leer

Este es el argumento más infravalorado. En Sanity, el modelo de contenido es código TypeScript, versionado en el repositorio. Cuando un agente abre mi proyecto, ve a la vez el front-end de Next.js, las consultas y la definición exacta de cada tipo de documento. No necesita ir a «descubrir» el modelo en una interfaz web: lo lee, igual que lee el resto del código.

Para alguien a quien le encantan las interfaces no-code, eso es una desventaja (hablaré de ello más adelante). Para un agente, es decisivo: todo el contexto está en un único lugar.

---

Qué cambió a nivel técnico

Localización a nivel de campo

Opté por la localización a nivel de campo: un documento por artículo, con campos que contienen un valor por idioma. El plugin oficial sanity-plugin-internationalized-array se encarga de ello:

// sanity.config.ts
import { defineConfig } from 'sanity'
import { internationalizedArray } from 'sanity-plugin-internationalized-array'
import { LOCALES } from './i18n/locales' // same source of truth as next-intl

export default defineConfig({
  // ...
  plugins: [
    internationalizedArray({
      languages: LOCALES.map((id) => ({ id, title: id.toUpperCase() })),
      fieldTypes: ['string', 'text'],
    }),
  ],
})

// schemas/post.ts
import { defineType, defineField } from 'sanity'

export const post = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'internationalizedArrayString' }),
    defineField({ name: 'excerpt', type: 'internationalizedArrayText' }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: (doc: any) => doc.title?.find((t: any) => t.language === 'en')?.value },
    }),
    defineField({ name: 'publishedAt', type: 'datetime' }),
    defineField({ name: 'cover', type: 'image', options: { hotspot: true } }),
  ],
})

¿Por qué a nivel de campo en lugar de un documento por idioma? Porque mis artículos comparten la mayoría de los elementos —fecha, imágenes, etiquetas, autores— y solo cambia el texto. Un único documento implica una única fuente de verdad, y un agente que lo traduzca solo tiene que aplicar cambios a un objeto.

Un detalle que puede hacerte perder una tarde: desde la versión 5 del plugin, el idioma se almacena en un campo language, ya no en _key. Los antiguos ejemplos con _key == "en" que aún circulan por internet ya no funcionan.

De Apollo y GraphQL a GROQ

Este fue el mayor trabajo en el front-end. Dejé Apollo Client en favor de next-sanity, GROQ y TypeGen.

Antes, con Hygraph:

// Before — Apollo + Hygraph GraphQL
const GET_POSTS = gql`
  query Posts($locale: Locale!) {
    posts(locales: [$locale, en], orderBy: publishedAt_DESC, first: 10) {
      title
      slug
      excerpt
      coverImage { url }
    }
  }
`
const { data } = await client.query({ query: GET_POSTS, variables: { locale } })

Después, con Sanity:

// After — next-sanity + GROQ
import { defineQuery } from 'next-sanity'

export const POSTS_QUERY = defineQuery(`
  *[_type == "post" && defined(slug.current)] | order(publishedAt desc)[0...10]{
    "title": coalesce(title[language == $locale][0].value, title[language == "en"][0].value),
    "excerpt": coalesce(excerpt[language == $locale][0].value, excerpt[language == "en"][0].value),
    "slug": slug.current,
    "cover": cover.asset->url
  }
`)

const posts = await client.fetch(POSTS_QUERY, { locale })

Después:

npx sanity typegen generate

TypeGen genera tipos TypeScript a partir del esquema y de las consultas. El resultado de POSTS_QUERY está tipado de extremo a extremo sin escribir a mano ni una sola interfaz.

Lo que gané: menos dependencias (se acabó Apollo, no hay que configurar ninguna caché del cliente), un idioma de respaldo definido directamente en la consulta con coalesce y proyecciones que devuelven exactamente la estructura que necesita el componente.

---

Lo que sigo reconociéndole a Hygraph

Sería deshonesto dejarlo ahí. Hygraph tiene puntos fuertes reales, y echo de menos algunos de ellos.

• GraphQL nativo. Es un estándar. Todo el mundo lo conoce, las herramientas están maduras y no quedas atado a un lenguaje propio.
• Localización nativa. En Hygraph, las configuraciones regionales son una funcionalidad de primer nivel: marcas un idioma y todos los campos pasan a ser localizables. Sin plugins ni configuración. Es más sencillo; simplemente, tiene un precio elevado.
• El generador de esquemas no-code. Una persona sin conocimientos técnicos puede hacer evolucionar por su cuenta el modelo de contenido desde la interfaz. En Sanity, eso es imposible sin tocar código.
• Federación de contenido. Conectar API externas y exponerlo todo tras un único endpoint de GraphQL es muy potente para una empresa con datos dispersos. Yo no lo necesitaba, pero es un verdadero factor diferenciador.

El modelo Blog Post de mi proyecto de Hygraph: campos localizados y tipos de campo disponibles en el generador de esquemas. Captura de pantalla de mi proyecto, octubre de 2026.

Si formas parte de un equipo de marketing mediano con pocos idiomas, editores sin conocimientos técnicos que quieren autonomía sobre el modelo y un presupuesto reservado para el CMS, Hygraph sigue siendo una opción muy buena.

Mi queja se refiere a algo concreto: su modelo de precios penaliza a los pequeños actores multilingües. Es una decisión empresarial legítima, pero hizo que quedara fuera de mi alcance.

---

En qué Sanity no es mejor

La misma honestidad en el otro sentido.

Tienes que aprender GROQ. Es un lenguaje propietario. Es potente, conciso y agradable una vez que lo conoces, pero supone otro tipo de dependencia: mis consultas ya no se pueden trasladar a otro CMS. Cambié conscientemente una dependencia de precios por una dependencia sintáctica. (Sanity también ofrece una API de GraphQL, pero se pierde gran parte de la ventaja.)

Todo pasa por el desarrollador. El esquema como código es estupendo para un desarrollador y para un agente. Para un editor sin conocimientos técnicos que quiera añadir un campo, es una puerta cerrada. En mi caso, yo soy el desarrollador, así que la cuestión no se plantea. En un equipo, sí.

La i18n es menos nativa. Tienes que elegir una estrategia (campo o documento), instalar un plugin, gestionar las migraciones entre versiones (el cambio de _key → language) y vigilar el límite de atributos únicos del conjunto de datos, que aumenta rápidamente con la localización a nivel de campo en siete idiomas. Nada insuperable, pero es un trabajo que Hygraph hace por ti.

---

Más allá del CMS: cómo elegir (y abandonar) una herramienta SaaS en 2026

Por encima de todo, esta migración me recordó una cosa: una herramienta no es una elección permanente, sino una elección para un momento concreto. Hygraph fue la decisión adecuada cuando construí el stack. Dejó de serlo cuando cambiaron mis necesidades.

Me quedo con tres lecciones, que también comparto con los clientes con los que trabajo.

1. Calcula el coste según tu trayectoria, no según tu situación actual. Las tablas de precios están diseñadas para que empezar resulte sencillo. Pregúntate: ¿cuánto costará esto con el doble de idiomas, contenido, sitios o colaboradores? Ahí es donde aparecen las diferencias.

2. En 2026, «¿puede usarlo un agente?» es un criterio de primer nivel. Una herramienta con un servidor MCP oficial, un modelo legible como código y una API automatizable te ahorrará horas cada semana. Una herramienta que solo puedas manejar con el ratón acabará convirtiéndose en un cuello de botella.

3. Mantén tu contenido portable. Pude migrar porque mi contenido estaba bien estructurado y el front end era mío. El día que cambies de herramienta, la calidad de tu modelo de contenido determinará si la migración tarda una semana o tres meses.

---

Lista de comprobación: cómo elegir un CMS headless

Esta es la lista de comprobación que utilizo ahora, tanto para mí como para mis clientes:

Contenido e idiomas

• ☐ ¿Cuántos idiomas tienes hoy? ¿Y dentro de dos años?
• ☐ ¿La localización está incluida, tiene un límite o se cobra por idioma?
• ☐ ¿Localización a nivel de campo, de documento o ambas?

Coste

• ☐ ¿Cuánto cuesta el siguiente plan y qué hace que tengas que pasar a él (usuarios, idiomas, entornos, cuotas)?
• ☐ ¿Cómo se contabilizan las llamadas a la API y qué ocurre si superas el límite?
• ☐ ¿El plan gratuito incluye un entorno de staging?

Equipo

• ☐ ¿Quién hace evolucionar el modelo de contenido: un desarrollador o un editor?
• ☐ ¿Necesitas colaboración en tiempo real?

Desarrollo

• ☐ ¿El esquema reside en el código y está versionado junto con el front end?
• ☐ ¿Lenguaje de consulta estándar (GraphQL) o propietario (GROQ…)? ¿Estás dispuesto a aprenderlo?
• ☐ ¿Los tipos se generan automáticamente?

IA y agentes

• ☐ ¿Hay un servidor MCP oficial?
• ☐ ¿Puede un agente leer el esquema y crear, editar y publicar contenido?
• ☐ ¿Incluye herramientas de traducción o generación y a qué coste?

Salida

• ☐ ¿Puedes exportar todo tu contenido en un formato abierto?
• ☐ ¿Cuánto costaría una migración dentro de dos años?

Responde a estas preguntas antes de elegir y evitarás la mayoría de las sorpresas desagradables. Respóndelas después, como hice yo, y al menos sabrás cuándo ha llegado el momento de marcharte.

---

Próximos pasos

Todo mi ecosistema reside ahora en un único proyecto de Sanity: los artículos de este blog, el contenido de ⌘+F y los episodios de ⌘+P. Un modelo, siete idiomas y agentes trabajando directamente en el CMS.

Hoy también animo a mis clientes a migrar a Sanity. Tres de ellos ya han dado el paso. Migrar los modelos de contenido y varios miles de páginas llevó solo unas horas: unas diez horas en los proyectos más grandes. Algunos clientes recuperaron el coste de la migración en tres meses.

Si estás evaluando tu stack de contenido, planteándote una migración o quieres conectar tus agentes de IA a tu CMS, ese es exactamente el tipo de trabajo que hago con BNC Consulting. Escríbeme.

Y si prefieres hablarlo con otros desarrolladores, únete a la comunidad ⌘+F: también compartimos este tipo de experiencias prácticas en encuentros, tomando un café o cenando.

— Clément