Zustand vs Redux Toolkit: The Honest Breakdown Nobody Gives You

My team picked Redux Toolkit at the start of a new project. The decision was easy — it's the official Redux recommendation, it has great DevTools, and everyone on the team already knew it. Three months later we ripped it out. Not because Redux Toolkit is bad. Because it was too much for what we actually needed. This is the honest breakdown I wish someone had given us before we started.

Zustand just crossed Redux Toolkit in weekly npm downloads in 2025. That's not a coincidence. Developers have been quietly making the same switch. The question is whether the switch makes sense for your project — and the answer depends on more than bundle size.

The Numbers

Zustand 5.0 ships at 486 bytes gzipped. Redux Toolkit ships at 13.6KB gzipped. That's a 28× size difference. On a throttled device, Zustand parses approximately 4× faster. These numbers matter on mobile — they don't move the needle on desktop.

• Zustand — 486B gzipped, ~3 files of boilerplate, surgical re-renders by default
• Redux Toolkit — 13.6KB gzipped, ~15 files of boilerplate, re-renders need manual reselect
• Zustand crossed Redux Toolkit in weekly npm downloads in 2025
• Same counter: RTK needs 15 files, Zustand needs 3

But bundle size isn't the real argument. The real difference shows up in three places: boilerplate, re-renders, and DevTools. Let's take each one.

Boilerplate: 15 Files vs 3

The boilerplate gap sounds trivial until you're onboarding someone at 11pm before a release. Here's the same feature — a modal toggle — implemented in both.

// Redux Toolkit — modal toggle
// modalSlice.ts
import { createSlice } from "@reduxjs/toolkit";

const modalSlice = createSlice({
  name: "modal",
  initialState: { isOpen: false },
  reducers: {
    openModal: (state) => { state.isOpen = true; },
    closeModal: (state) => { state.isOpen = false; },
  },
});

export const { openModal, closeModal } = modalSlice.actions;
export default modalSlice.reducer;

// store.ts — add to combineReducers
// hooks.ts — typed useAppDispatch + useAppSelector
// Component usage:
const isOpen = useAppSelector((s) => s.modal.isOpen);
const dispatch = useAppDispatch();
dispatch(openModal());

// Zustand — same modal toggle, one file
import { create } from "zustand";

const useModalStore = create<{
  isOpen: boolean;
  open: () => void;
  close: () => void;
}>()((set) => ({
  isOpen: false,
  open: () => set({ isOpen: true }),
  close: () => set({ isOpen: false }),
}));

// Component usage — that's it
const { isOpen, open, close } = useModalStore();

For a modal. The Redux Toolkit version touches 4 files minimum. The Zustand version is self-contained. Multiply this across 20 features and you understand why teams are switching.

Re-renders: Surgical vs Manual

This is where Zustand's design philosophy becomes concrete. By default, a component re-renders when any part of the store it reads changes. Redux Toolkit has the same problem without Reselect. Zustand's selector pattern is surgical — subscribe to exactly what you need.

// Bad — re-renders whenever ANY store value changes
const { filters, pagination, user } = useAppStore();

// Good — only re-renders when filters.status changes
const status = useAppStore((s) => s.filters.status);

// Good — derived selector, re-renders only when count changes
const activeCount = useAppStore(
  (s) => Object.values(s.filters).filter(Boolean).length
);

// Zustand compares selector output by reference equality —
// no extra memoization library required.

I migrated a high-churn dashboard from prop-drilled Context to Zustand and the render noise disappeared overnight. The case filter panel, results table, and pagination — all previously re-rendering in lockstep — became independent. Each component subscribed to its own slice and re-rendered in isolation.

DevTools: Where Redux Toolkit Genuinely Wins

This is the honest part nobody says. Redux DevTools — time-travel debugging, action replay, state export — is not replicated by Zustand. If you're in a regulated industry (legal, finance, healthcare), debugging a race condition from three async actions ago is invaluable. Redux's action log is a linear, inspectable history of your entire state. Zustand's middleware logger exists but it's basic.

• Time-travel debugging — step backwards through state changes
• Action replay — reproduce bugs from production logs
• State export/import — share exact app state with teammates
• Diff view — see exactly what changed per dispatch

If your team lives in Redux DevTools every day, don't switch. If you've opened it twice in six months, it's not a real argument for keeping Redux Toolkit.

The Modern Pattern: TanStack Query + Zustand

Here's what I actually reach for now, and why it covers 90% of React apps with almost zero overhead.

"Most 'state management' problems are actually server state problems. Conflating the two is what leads to 80-line Redux slices managing data that should just be a cache."

TanStack Query handles everything that comes from the server: fetching, caching, background refetching, stale-while-revalidate, optimistic updates. Zustand handles everything that is genuinely client-side: UI state, filters, selections, modals, multi-step wizard progress.

// TanStack Query — server state
const { data: cases, isLoading } = useQuery({
  queryKey: ["cases", filters],
  queryFn: () => fetchCases(filters),
  staleTime: 30_000,
});

// Zustand — client state
const filters = useCaseStore((s) => s.filters);
const setFilter = useCaseStore((s) => s.setFilter);

// No manual loading state. No Redux thunks.
// No normalization. Just: what does the server give us,
// and what has the user selected locally.

When to Use Redux Toolkit

• Large teams (10+ engineers) where consistent patterns matter more than flexibility
• Complex async orchestration — Redux-Saga or Redux-Thunk with heavy side effects
• Codebases already deep in Redux where migration cost exceeds benefit
• Regulated industries where DevTools time-travel is a debugging requirement
• Apps with normalized entity caching (Redux Toolkit's createEntityAdapter is excellent)

When to Use Zustand

• Small to medium teams who ship fast and hate boilerplate
• Apps where 80%+ of state comes from a server (pair with TanStack Query)
• Greenfield projects — start simple, scale up only when you hit real limits
• When you need state outside of React components (utility functions, event handlers)
• Micro-frontends — each remote can own its store without global provider hell

The Mistake I Still See Constantly

Teams adding Redux Toolkit to a three-person startup that ships every two weeks. Six months later they're maintaining 80-line slices for a modal toggle. The framework isn't the problem. The mismatch between tool complexity and actual problem complexity is the problem.

Pick the tool that stays out of your way. For most teams in 2026, that's TanStack Query + Zustand. For teams with genuinely complex async state and large codebases, Redux Toolkit earns its weight. Know which situation you're actually in before you start typing.

"The best state management setup is the one your newest team member can understand on day one without reading documentation."