RTK Query frente a TanStack Query

Después de cuatro lecciones exprimiendo RTK Query toca la pregunta incómoda: en 2026, con TanStack Query como estándar de facto del data-fetching en React y con presencia ya en Vue, Svelte, Solid y Angular, ¿tiene sentido seguir eligiendo la cache de Redux? La respuesta honesta no es un empate diplomático ni una preferencia disfrazada de argumento. Ambas resuelven el mismo problema —el estado de servidor como cache y no como estado— y ambas lo resuelven bien; sus catálogos de funcionalidades convergieron hace años y comparar listas de opciones no distingue nada. Lo que sí distingue es que parten de dos ideas incompatibles sobre qué es una entrada de cache y quién decide su identidad. Todo lo demás —la ergonomía, la invalidación, el tamaño, la portabilidad— se deduce de esa raíz, y entenderla es lo que convierte la elección en una decisión de arquitectura en lugar de una preferencia de gusto.

Dos ontologías de la entrada de cache

En RTK Query una entrada de cache existe porque tú declaraste un endpoint. El catálogo es cerrado y conocido en tiempo de compilación: listarPosts existe, listarComentarios no existe hasta que lo añadas, y el sistema de tipos lo sabe. La identidad de una entrada es el par de nombre de endpoint y argumento serializado, y el argumento es un valor único cuyo tipo declaraste. De esa clausura salen las capacidades más distintivas de la librería: los hooks generados por nombre, la seguridad de tipos extremo a extremo sin anotaciones y las etiquetas restringidas a un vocabulario que TypeScript verifica.

En TanStack Query una entrada existe porque alguien la pidió. La identidad es un array arbitrario de valores serializables —la clave de consulta— y la obtención es cualquier función que devuelva una promesa. No hay catálogo, no hay registro previo, no hay nombre que declarar. Esto abre un espacio infinito de entradas y con él una libertad estructural: las claves son jerárquicas por convención, de modo que un array que empieza igual que otro se considera su prefijo, y sobre esa jerarquía se construye toda la invalidación.

// RTK Query: catalogo cerrado. La entrada existe porque el endpoint existe.
const { data } = useObtenerPostQuery(id);

// TanStack Query: espacio abierto. La entrada existe porque la clave se uso.
const { data } = useQuery({
  queryKey: ["posts", "detalle", id],
  queryFn: () => obtenerPost(id),
  staleTime: 30_000,
});

Esa diferencia de dos líneas contiene todo lo demás. En la primera, la librería sabe qué endpoints hay y puede generar código; en la segunda, la librería no sabe nada del dominio y a cambio acepta cualquier fuente asíncrona, venga de HTTP, de IndexedDB, de un websocket o de un cálculo caro en un worker.

La clausura del catálogo tiene una virtud que se nota poco y se agradece mucho: hace que la superficie de red de una aplicación sea enumerable. Puedes abrir un fichero y leer todo lo que tu cliente le pide a su backend, con sus tipos y sus etiquetas, sin buscar llamadas dispersas. Esa propiedad no es técnica sino organizativa, y explica por qué RTK Query encaja tan bien en equipos grandes: el contrato con el servidor deja de ser folclore repartido entre carpetas y se vuelve un documento. La apertura de TanStack Query renuncia a esa enumerabilidad por defecto, aunque un equipo disciplinado puede recuperarla imponiéndose una fábrica de claves y un módulo de funciones de obtención. La diferencia es quién garantiza el orden: la librería o la costumbre.

Invalidación declarada frente a invalidación por prefijo

La consecuencia más visible de las dos ontologías es cómo se dice que algo caducó. RTK Query lo dice con el grafo de etiquetas que construiste en la segunda lección: la consulta declara qué provee, la mutación qué invalida, y ninguna conoce a la otra. TanStack Query lo dice invalidando claves, normalmente por prefijo, desde el cliente de consultas.

// TanStack Query: invalidacion imperativa por prefijo de clave.
const cliente = useQueryClient();

const editar = useMutation({
  mutationFn: guardarPost,
  onSuccess: (_datos, post) => {
    cliente.invalidateQueries({ queryKey: ["posts", "detalle", post.id] });
    cliente.invalidateQueries({ queryKey: ["posts", "lista"] });
  },
});

La comparación es reveladora en ambas direcciones. A favor de las etiquetas: la relación es declarativa y bidireccionalmente ciega, de modo que una consulta nueva que provea Post entra automáticamente en el grafo sin que nadie edite ninguna mutación, y el vocabulario cerrado convierte un error de escritura en un error de compilación. A favor de las claves: la jerarquía por prefijo es una intuición inmediata que no requiere aprender un segundo concepto, y permite invalidar subárboles enteros con una expresión que se lee sola. El coste de las claves es que la mutación sí conoce a las consultas —hay que enumerar qué invalidar— y que un cambio en el esquema de claves rompe en silencio invalidaciones que dejan de casar, sin que ningún tipo avise. Ese silencio es el precio de la apertura.

La mitigación estándar de ese silencio es la fábrica de claves, un módulo que centraliza la construcción de cada clave y elimina las cadenas escritas a mano. Merece adoptarse desde el primer día, porque convierte un espacio abierto en uno gobernado sin renunciar a su flexibilidad, y porque restituye la enumerabilidad que la clausura de RTK Query regala.

export const clavesPost = {
  todo: ["posts"] as const,
  listas: () => [...clavesPost.todo, "lista"] as const,
  lista: (filtro: string) => [...clavesPost.listas(), filtro] as const,
  detalle: (id: string) => [...clavesPost.todo, "detalle", id] as const,
};

// Invalidar todas las listas sin tocar los detalles ya cargados.
cliente.invalidateQueries({ queryKey: clavesPost.listas() });

Con esa fábrica, la invalidación por prefijo alcanza una expresividad que las etiquetas no tienen: puedes derribar un subárbol completo con una sola expresión, sin haber declarado por adelantado ninguna relación. Es el reflejo exacto de la ventaja contraria. Las etiquetas te obligan a nombrar el vocabulario y te pagan con verificación; las claves te dejan improvisar la jerarquía y te pagan con alcance.

flowchart TD
A[necesito una cache de servidor] --> B{ya uso Redux para estado de cliente?}
B -->|si, y de forma central| C[RTK Query]
B -->|no| D{necesito cachear fuentes no HTTP?}
D -->|si| E[TanStack Query]
D -->|no| F{comparto codigo con otro framework?}
F -->|si| E
F -->|no| G[TanStack Query por defecto]
C --> H[una sola DevTool y un solo store]
E --> I[independencia total del gestor de estado]
style C fill:#cba6f7,color:#11111b
style E fill:#f38ba8,color:#11111b
style G fill:#a6e3a1,color:#11111b

Costes de entrada, de salida y de portabilidad

El coste de entrada de RTK Query es cero si ya tienes Redux Toolkit —viene en el mismo paquete, comparte store, middleware y DevTools— y es alto si no lo tienes, porque adoptarlo significa adoptar Redux entero: proveedor, store, middleware y el modelo mental completo. El de TanStack Query es siempre el mismo y siempre bajo: un proveedor y un cliente, sin ninguna opinión sobre dónde vive tu estado de cliente.

Ese coste de entrada asimétrico explica una observación empírica: prácticamente nadie adopta Redux por RTK Query, mientras que mucha gente adopta RTK Query por tener ya Redux. La causalidad va siempre en el mismo sentido, y esa direccionalidad es la primera pista de que la comparación no se decide en el terreno de la cache.

El coste de salida es más interesante y casi nadie lo calcula. Salir de RTK Query implica reescribir endpoints y hooks, pero la frontera es estrecha porque los hooks generados tienen nombres previsibles y las consultas están todas en un fichero: la migración es mecánica y localizable. Salir de TanStack Query es igual de mecánico pero más disperso, porque las claves y las funciones de obtención viven allá donde se usaron, salvo que hayas impuesto tú mismo la disciplina de una fábrica de claves centralizada, que es exactamente lo que la librería te deja hacer y no te obliga a hacer.

En portabilidad no hay discusión. TanStack Query tiene adaptadores oficiales para React, Vue, Svelte, Solid y Angular sobre un núcleo común, de modo que un equipo con productos en varios frameworks reutiliza no solo el conocimiento sino las propias claves y funciones. RTK Query tiene una capa agnóstica de framework, pero su ergonomía real —los hooks generados— es de React, y en la práctica es una elección de ecosistema React con Redux.

Sobre el peso conviene ser preciso porque circulan cifras engañosas en las dos direcciones. Comparar RTK Query con TanStack Query a secas favorece al primero, que reutiliza infraestructura ya presente si Redux Toolkit está instalado. Comparar la adopción completa —store, proveedor, middleware, reducers y la cache— favorece claramente al segundo, que no arrastra nada. La comparación honesta no es entre dos paquetes sino entre dos incrementos: cuánto añade cada opción sobre lo que tu proyecto ya tiene hoy. Y ese incremento depende de una decisión que no es de cache.

El criterio

Con las ontologías, la invalidación y los costes sobre la mesa, la decisión ya no necesita ninguna tabla comparativa: necesita mirar hacia dentro, a lo que tu proyecto es hoy.

Reducido a lo esencial, el criterio cabe en tres frases. Si tu aplicación ya usa Redux de forma central para estado de cliente y el equipo vive en sus DevTools, RTK Query es la elección obvia: aprovechas la infraestructura existente, evitas una segunda librería de cache y ganas la coherencia de que todo —cliente y servidor— sea inspeccionable en el mismo lugar. Si no usas Redux, adoptarlo entero para tener RTK Query casi nunca se justifica, porque estarías pagando el modelo mental completo de un gestor de estado global por una capacidad que otra librería te da sin condiciones. Y si trabajas con varios frameworks o necesitas cachear fuentes que no son HTTP, TanStack Query gana sin matices.

Hay un caso intermedio que el criterio anterior deja fuera y que aparece más de lo que se admite: el proyecto que tiene Redux pero apenas lo usa, con dos slices heredados de una decisión antigua y todo lo demás resuelto con estado local. Ahí la respuesta correcta no es adoptar RTK Query para aprovechar el store, sino reconocer que ese store ya no se gana su sitio. La cache de servidor no debe ser el argumento que mantenga viva una infraestructura que nadie usaría hoy; si el Redux existente solo se justifica porque RTK Query viene con él, la cola está moviendo al perro. Migrar esos dos slices a Zustand o a estado local y adoptar TanStack Query deja una arquitectura más pequeña que cualquiera de las dos mitades por separado.

Conviene añadir una observación sobre la trayectoria, no para predecir sino para calibrar. En 2026 el patrón dominante en aplicaciones nuevas de React es TanStack Query para el servidor con Zustand o Jotai para el cliente, y Redux Toolkit ha quedado como la elección deliberada de equipos grandes, dominios auditables o bases de código con años de historia. Eso no convierte a RTK Query en obsoleto —está mantenido, es excelente y sigue siendo la mejor cache posible dentro de Redux— pero sí significa que la pregunta relevante rara vez es cuál de las dos caches es mejor, sino si tu aplicación debía tener Redux en primer lugar. Contestada esa, la cache se deduce.