Zustand vs Redux Toolkit vs Jotai: State Management in 2026

Honestly, Most Projects Don't Need Redux

Honestly, the Redux debate should've ended years ago — but here we are in 2026 and developers are still reaching for it by default. That's not a knock on Redux Toolkit specifically. RTK cleaned up a lot of the old Redux mess. But installing it for a three-page SaaS dashboard is like renting a warehouse to store a bike.

The state management landscape has genuinely shifted. Zustand hit v5.0 last year with a tighter API surface, Jotai 2.x landed first-class React Server Component support, and Redux Toolkit 2.x brought RTK Query improvements that made the data-fetching story much cleaner. They're all good now. The question is which one fits your actual use case.

This article breaks down all three honestly — setup cost, bundle size, mental model, and where each one actually shines. No sponsored opinions.

Bundle Size and Setup Cost: The Numbers Matter

Let's start with the thing that's easiest to measure. Zustand weighs in around 1.1 kB gzipped. Jotai is roughly 2.4 kB. Redux Toolkit with React-Redux is about 14 kB combined. That difference is real, especially if you're building something like a component library — and if you're using something like Empire UI where bundle size compounds across many consumers, it matters a lot.

Setup is where the gap widens further. A Zustand store for a shopping cart takes maybe 12 lines. Jotai needs just an atom declaration. Redux Toolkit still wants a slice, a store configuration, a Provider wrapper, and a typed hook setup. You can scaffold most of it quickly, but there's cognitive weight there that never fully goes away.

That said, RTK's boilerplate pays dividends on large teams. The structure is opinionated in a way that makes pull request reviews predictable. When six developers are touching global state simultaneously, "more setup" often means "fewer surprises".

Zustand: The Developer Favorite for a Reason

Zustand's model is dead simple. You define a store with a function, you read from it with a hook, you update state inside actions. There's no dispatch. No reducers. No actions as separate objects. The whole thing collapses into one mental model instead of three.

Here's what a realistic Zustand store looks like for a UI state manager — the kind of thing you'd pair with a component library using theme toggling:

import { create } from 'zustand'
import { devtools, persist } from 'zustand/middleware'

type Theme = 'light' | 'dark' | 'system'

interface UIStore {
  theme: Theme
  sidebarOpen: boolean
  setTheme: (theme: Theme) => void
  toggleSidebar: () => void
}

export const useUIStore = create<UIStore>()(
  devtools(
    persist(
      (set) => ({
        theme: 'system',
        sidebarOpen: true,
        setTheme: (theme) => set({ theme }, false, 'setTheme'),
        toggleSidebar: () =>
          set((s) => ({ sidebarOpen: !s.sidebarOpen }), false, 'toggleSidebar'),
      }),
      { name: 'ui-store' }
    )
  )
)

The devtools middleware hooks into Redux DevTools Extension without any extra setup. The persist middleware syncs to localStorage with one config line. You get 90% of RTK's debugging experience for about 15% of the setup. That's the honest reason Zustand is the top pick on npm for lean React projects in 2026.

Jotai: Atomic State That Actually Makes Sense

Jotai's pitch is different. Where Zustand gives you a store object, Jotai gives you atoms — individual pieces of state that compose together. It's closer to how React's own useState works, just lifted to a shareable level. If you've ever had useState hell with prop drilling through five components, Jotai is the natural upgrade path.

The killer feature in Jotai 2.x is derived atoms. You define a base atom, then you derive computed values from it synchronously or asynchronously without any selector machinery. There's also first-class support for async atoms that suspend — meaning you can write data-fetching state that integrates directly with React Suspense. It's surprisingly elegant.

Where Jotai gets tricky is on very large state graphs. Atoms multiplied across hundreds of features can become hard to trace. There's no single store to inspect — your state is scattered across atom declarations. Debugging with React DevTools helps, but it's not as smooth as Redux's time-travel or Zustand's devtools middleware. Worth knowing upfront.

Redux Toolkit in 2026: Still Worth It for Complex Apps

RTK has a bad reputation it mostly doesn't deserve anymore. Redux Toolkit 2.x slashed the boilerplate significantly. createSlice handles action creators automatically. RTK Query handles server state with caching, polling, and optimistic updates. If you're building a product with a complex data layer — think a multi-tenant SaaS with real-time updates and an offline mode — RTK is still a serious choice.

The real case for RTK isn't ergonomics, it's team scale. When you have a backend engineer writing the API and a frontend team of five managing global state, RTK's strict conventions become documentation. New joiners understand where to look. State transitions are traceable. The DevTools time-travel debugger actually helps find production bugs. That stuff compounds.

Is RTK overkill for your next project? Probably. But the question isn't "is it overkill in general" — it's whether your team size, your domain complexity, and your debugging needs justify the overhead. For many serious products, they do.

When to Pick Which: A Practical Decision Matrix

Here's the mental model I use. Zustand wins when you need shared UI state, client-only logic, and a small-to-medium team. Think: sidebar state, modal queues, user preferences, multi-step form state across routes. It plays nicely with Vite-based setups where you want minimal runtime overhead.

Jotai wins when your state naturally decomposes into independent units that happen to need sharing. Design systems, widget grids, per-component config flags. It's also the right call if you're leaning hard into React Suspense and want your async data to live in the same mental model as your sync state.

Redux Toolkit wins when you're building a large-scale app with a dedicated team, a complex domain model, and an existing investment in the Redux ecosystem. RTK Query in particular is underrated for teams that don't want to add React Query on top of an existing RTK setup. Pick the tool that matches the problem, not the one that has the most GitHub stars.

And if you're wondering about server state — Zustand and Jotai both defer to TanStack Query (formerly React Query) for that. RTK Query competes directly. None of these libraries are server state managers by default; don't use them that way.

Performance: Subscriptions, Rerenders, and What Actually Matters

All three libraries handle selective subscription to avoid unnecessary rerenders. Zustand uses selector functions — you pass a selector to useUIStore and only re-render when that slice changes. Jotai does this by design since you subscribe to individual atoms. RTK's useSelector works similarly, with the added option of createSelector (via Reselect) for memoized derived state.

In practice, rerender performance is rarely the bottleneck for most apps. Where it matters is in data-dense UIs — virtual lists, real-time dashboards, canvas-heavy apps. In those cases, Jotai's atom-level granularity gives you the most surgical control. Zustand's selectors are good enough for 95% of cases and simpler to write. RTK's selector system is the most powerful but also the most ceremonial to set up.

Worth noting: if you're using a component library like Empire UI with glassmorphism effects where animated style tokens change reactively, fine-grained subscriptions matter. A single global theme atom in Jotai — or a scoped Zustand selector — is usually the right shape for that.

Migrating Between Them: Not as Bad as You Think

Here's something nobody talks about: you can run two of these at once during a migration. Zustand and Jotai don't conflict with each other or with Redux. A codebase in 2026 running RTK for legacy features and Zustand for new ones isn't a mess — it's pragmatic. The bundle cost is real, so don't do it indefinitely, but for a phased migration it's totally viable.

Moving from Redux to Zustand usually takes the form of identifying your most painful slices, rewriting them as Zustand stores, and progressively removing RTK dependencies. The hardest part is RTK Query — if you've built data fetching on top of it, you'll need to either stay on RTK or replace it with TanStack Query. Plan for that specifically.

The question isn't really which library wins — it's whether you'd pick the same one again knowing what you know now. That reflection is more useful than any benchmark. If you're starting fresh in 2026 with a Next.js or Astro project, Zustand is probably your fastest path to shipping state that doesn't fight you.

FAQ

Read next