Zustand vs Redux Toolkit: 0.14 ms vs 0.68 ms per Update

I bumped one row in a 1,000-row React 19 list 300 times per trial: Zustand 5.0.15 took a median 0.14 ms per update, Redux Toolkit 2.13.0 with react-redux 9.3.0 took 0.68 ms, about 5× slower. Both re-rendered exactly 1 row per update, and Zustand's hook shipped 0.4 KB gzip against 9.7 KB for RTK plus react-redux.

Short answer: pick Zustand for new React apps whose state is mostly client UI state. Keep Redux Toolkit if you already run it, rely on Redux DevTools time travel, or use RTK Query. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM shared Linux cloud box, tested 6 Oct 2026 about 00:38–00:42 IST.
• Versions: zustand 5.0.15, @reduxjs/toolkit 2.13.0 (redux 5.0.1, immer 11.1.21), react-redux 9.3.0, React 19.3.0, jsdom 29.1.1, Node 22.20.0.
• Fixture: /workspace/bench-zustand-rtk/. One normalized map of 1,000 items { id, done, count }. The action bumps one item's count. Zustand uses an immutable spread; RTK uses a createSlice reducer with Immer.
• React test: 1,000 <li> rows, each subscribed to its own item with a selector (useStore vs useSelector). 300 flushSync updates per trial, 7 trials after a warm-up, NODE_ENV=production, run twice.
• Store test: no React, 1 subscriber, 20,000 updates per round, 9 timed rounds after one warm round.
• Findings: React per-update median 0.137 ms (Zustand) vs 0.676 ms (RTK) on run 2, and 0.139 vs 0.694 ms on run 1. Mounting 1,000 rows took about 10.6 ms vs 9.0 ms, so RTK mounted slightly faster. Store-only: Zustand 1,376,191 updates/s vs RTK 6,502 updates/s.
• One surprise: almost all of RTK's store-only cost was Immer's auto-freeze on the 1,000-item state, not the Redux dev checks.
• Not tested: Redux DevTools, RTK Query, createEntityAdapter, Zustand middleware (persist, immer, devtools), React Native, real browsers, SSR hydration.

How big was the React update gap?

Setup (1,000 rows, 300 updates)	Median ms per update	Rows re-rendered per update
Zustand useStore + selector	0.137	1
RTK default middleware + useSelector	0.676	1
RTK with immutable/serializable checks off	0.616	1
RTK with checks off and Immer autoFreeze off	0.758	1

Both libraries got the important part right: one changed item re-rendered one row. The gap is overhead around that render. Turning off RTK's dev checks or Immer freezing did not close it in the React test. At 0.68 ms per update, RTK is still far inside a 16 ms frame. You would only feel this with many updates per second, such as live tickers, drag interactions or a large table. For DOM test environments, my jsdom vs happy-dom run has the timing side.

Why was the store-only gap so large?

Store only (Node, production)	Updates per second
Zustand setState with spread	1,376,191
RTK default middleware	6,502
RTK with checks off	6,657
RTK with checks off and Immer autoFreeze off	386,966

Without React, Zustand ran about 200× more updates per second. Turning off RTK's immutable and serializable checks barely moved it. Turning off Immer's auto-freeze took RTK from 6,657 to 386,966 updates/s. In development mode the default RTK store dropped to 2,720 updates/s, because those dev checks walk the state too. Treat this as the cost of Immer on a 1,000-item map, not something you will see one-for-one in a UI. The React numbers above are the ones to plan with.

Does bundle size matter here?

Yes, a little. With React excluded and production mode set, esbuild minified Zustand's create to 624 B (387 B gzip). configureStore + createSlice + react-redux's Provider, useSelector and useDispatch came to 25,039 B (9,708 B gzip). Installed trees were about 95 KB for Zustand against about 9.2 MB for RTK, react-redux, redux, immer, reselect and redux-thunk. To keep that number honest in CI, see size-limit vs bundlesize.

Should you switch from Redux Toolkit to Zustand?

Situation	My pick
New React app, mostly UI state	Zustand
Existing RTK app with passing tests	Stay on RTK
Heavy server data fetching with caching	RTK Query, or a data-fetching library beside Zustand
Large team that wants one enforced pattern	RTK
High-frequency updates (drag, tickers, big tables)	Zustand
Need DevTools time travel out of the box	RTK

If you migrate, remove the leftovers afterwards: knip vs depcheck finds unused packages. Store tests run fine in either runner from my Jest vs Vitest comparison. For React 19 features that touch rendering, see my React 19.3 notes.

Bottom line: in a 1,000-row React 19 list, Zustand 5.0.15 handled an update in 0.14 ms against 0.68 ms for Redux Toolkit 2.13.0, with the same 1 row re-rendered, and shipped 0.4 KB gzip against 9.7 KB. Who should not switch: teams with a working RTK codebase, RTK Query endpoints or a habit of debugging through Redux DevTools. 0.5 ms per update will not justify a rewrite.

How this was made: I installed both libraries on the ShopperCove box, rendered the same 1,000-row list under jsdom, timed flushSync updates and store-only dispatch loops, measured esbuild bundle sizes and recorded the JSON. The write-up was drafted with AI help and checked against that output.

Sources

• https://zustand.docs.pmnd.rs/
• https://www.npmjs.com/package/zustand
• https://redux-toolkit.js.org/
• https://react-redux.js.org/
• https://immerjs.github.io/immer/freezing
• https://www.npmjs.com/package/@reduxjs/toolkit

Related

• https://www.shoppercove.com/blog/jsdom-vs-happy-dom-vitest
• https://www.shoppercove.com/blog/size-limit-vs-bundlesize
• https://www.shoppercove.com/blog/knip-vs-depcheck
• https://www.shoppercove.com/blog/jest-vs-vitest
• https://www.shoppercove.com/blog/react-19-3-view-transitions-fragment-refs-2026
• https://www.shoppercove.com/blog/vite-vs-parcel
• https://www.shoppercove.com/blog/source-map-explorer-vs-webpack-bundle-analyzer
• https://www.shoppercove.com/blog/zod-vs-valibot