How can I use zustand persist with indexeddb?

[CherphAlt]

Indexeddb can store more data than localstorage and other types of storage ? How can I use it with zustand?
I saw that it can be used with indexeddb in the persist guide but there was no example

[dai-shi]

I think someone did persist+indexedeb before (but maybe with old options).
Hope someone can help on this.

[JacobWeisenburger]

feel free to use this template:
Zustand custom persist storage template

If you found my answer satisfactory, please consider supporting me. Even a small amount is greatly appreciated. Thanks friend! 🙏
https://github.com/sponsors/JacobWeisenburger

[fredericrous]

From the docs, the recommended way to use indexeddb is as follow

import { create } from 'zustand'
import { persist, createJSONStorage, StateStorage } from 'zustand/middleware'
import { get, set, del } from 'idb-keyval' // can use anything: IndexedDB, Ionic Storage, etc.

// Custom storage object
const storage: StateStorage = {
  getItem: async (name: string): Promise<string | null> => {
    console.log(name, 'has been retrieved')
    return (await get(name)) || null
  },
  setItem: async (name: string, value: string): Promise<void> => {
    console.log(name, 'with value', value, 'has been saved')
    await set(name, value)
  },
  removeItem: async (name: string): Promise<void> => {
    console.log(name, 'has been deleted')
    await del(name)
  },
}

export const useBoundStore = create(
  persist(
    (set, get) => ({
      bears: 0,
      addABear: () => set({ bears: get().bears + 1 }),
    }),
    {
      name: 'food-storage', // unique name
      storage: createJSONStorage(() => storage),
    },
  ),
)

https://docs.pmnd.rs/zustand/integrations/persisting-store-data#how-can-i-use-a-custom-storage-engine

[KingXP-Pythoner]

From the docs, the recommended way to use indexeddb is as follow

import { create } from 'zustand'
import { persist, createJSONStorage, StateStorage } from 'zustand/middleware'
import { get, set, del } from 'idb-keyval' // can use anything: IndexedDB, Ionic Storage, etc.

// Custom storage object
const storage: StateStorage = {
  getItem: async (name: string): Promise<string | null> => {
    console.log(name, 'has been retrieved')
    return (await get(name)) || null
  },
  setItem: async (name: string, value: string): Promise<void> => {
    console.log(name, 'with value', value, 'has been saved')
    await set(name, value)
  },
  removeItem: async (name: string): Promise<void> => {
    console.log(name, 'has been deleted')
    await del(name)
  },
}

export const useBoundStore = create(
  persist(
    (set, get) => ({
      bears: 0,
      addABear: () => set({ bears: get().bears + 1 }),
    }),
    {
      name: 'food-storage', // unique name
      storage: createJSONStorage(() => storage),
    },
  ),
)

https://docs.pmnd.rs/zustand/integrations/persisting-store-data#how-can-i-use-a-custom-storage-engine

I attempted to follow your answer and also referenced the docs in my Nextjs 14 stack project where I use Dexie.js instead of idb-keyval. However, im unable to rehydrate the store. I always get the warning that it couldn't find the storage.

[fredericrous]

with Remix I insure indexeddb is opened by putting in my clientLoader a code like this

  const dbExists = await new Promise(resolve => {
    const request = indexedDB.open('app-storage')
    request.onsuccess = event => {
      resolve(true)
    }
    request.onerror = event => {
      resolve(false)
    }
  })
  const apps = dbExists ? selectApps(useAppsStore.getState()) : []

[KingXP-Pythoner]

Literally after you sent your reply, I realized I initialized my custom storage below the useStore and used createJSONStorage. For some reason, it didn't throw an error regarding using the object before initialization. Can't believe I made such a noob mistake. But thank you for your reply. It triggered my brain to realize the mistake haha.

[learnuidev]

Here is how I use index db and zustand:

import { create, StateCreator } from "zustand";
import { persist, createJSONStorage, StateStorage } from "zustand/middleware";
import { get, set, del } from "idb-keyval"; // can use anything: IndexedDB, Ionic Storage, etc.

// Custom storage object
export const indexDBStorage: StateStorage = {
  getItem: async (name: string): Promise<string | null> => {
    console.log(name, "has been retrieved");
    return (await get(name)) || null;
  },
  setItem: async (name: string, value: string): Promise<void> => {
    console.log(name, "with value", value, "has been saved");
    await set(name, value);
  },
  removeItem: async (name: string): Promise<void> => {
    console.log(name, "has been deleted");
    await del(name);
  },
};

export const createIndexDBStore = <T extends object>({
  name,
  handler,
}: {
  name: string;
  handler: StateCreator<T>;
}) =>
  create(
    persist(handler, {
      name, // name of the item in the storage (must be unique)
      storage: createJSONStorage(() => indexDBStorage), // (optional) by default, 'localStorage' is used
    })
  );

// Usage
export const useRepeatHistoryStore = createIndexDBStore({
  name: "mandarino/repeat-history",
  handler: (set: any, get: any) => ({
    history: [],
    setHistory: (event: any) => set({ history: get().history.concat(event) }),
    clearHistory: (event: any) => set({ history: [] }),
  }),
});

[kettanaito]

Almost all suggestions here still use createJSONStorage, which defeats the whole point of using IndexedDB. You don't need to serialize your data. If you want to store serializable data, use other web storages, like localStorage. The point of IndexedDB is that it can store non-serializable data: class instances, functions, etc.

Otherwise, the suggestions are solid when it comes to implementing your own persist:

import type { PersistStorage } from 'zustand/middleware'
import { get, set, del as remove, type UseStore } from 'idb-keyval'

export function createIndexedDbStorage(
  store: UseStore,
): PersistStorage<any, Promise<void>> {
  return {
    async getItem(key) {
      return await get(key, store).then((value) => value || null)
    },
    async setItem(key, value) {
      await set(key, value, store)
    },
    async removeItem(key) {
      await remove(key, store)
    },
  }
}

export const store = createStore(
  persist(() => ({}), {
    name: 'this-will-be-used-as-a-field-name',
    version: 0.1,
    storage: createIndexedDbStorage(
      createIndexedDbStore('indexeddb-database-name', 'indexeddb-store-name'),
    ),
  }),
)

[!IMPORTANT] Bear in mind that when using idb-keyval you cannot have multiple stores within the same database. You cannot do createIndexedDbStore('db', 'one') and createIndexedDbStore('db', 'two'). You either use the same db+store pair or opt out from idb-keyval as stated in their README.

[dai-shi]

• Created https://www.npmjs.com/package/zustand-indexeddb and sent an invitation.
• Could you rename the repo to https://github.com/zustandjs/zustand-indexeddb ?
• I configured Trusted Publishers for that repository. You should be able to check the configuration too.

[kettanaito]

Thanks, that's a much better approach! NPM_TOKEN shouldn't be needed with this. I will try publishing the package once I have a moment.

Did you have the chance to review it? I have a few things I'd like to solve, especially type-wise. How do I correctly annotate a persist storage to notify the consumer that setItem and getItem became asynchronous? Zustand doesn't seem to infer that despite the storage being provided type arguments <S, Promise<void>>.

[dbritto-dev]

@kettanaito what about something like this, basically creating your own PersistStorage type helper:

import type { StorageValue } from 'zustand/middleware/persist'

export interface PersistStorage<S> {
  getItem: (
    name: string,
  ) => Promise<StorageValue<S> | null>
  setItem: (name: string, value: StorageValue<S>) => Promise<void>
  removeItem: (name: string) => Promise<void>
}

export function createIndexedDBStorage<S>(
  databaseName: string,
  storeName: string,
): PersistStorage<S> {

[kettanaito]

Isn't this what PersistStorage does out of the box? https://github.com/zustandjs/zustand-indexeddb/blob/ed65d124a2c37cf841df6938179c09f0df773513/src/index.ts#L19-L22

[dbritto-dev]

@kettanaito yes and no, getItem return type is StorageValue<S> | null | Promise<StorageValue<S> | null> instead of only Promise<StorageValue<S> | null>

[dai-shi]

Did you have the chance to review it? I have a few things I'd like to solve, especially type-wise.

Hi, I looked at the code and it's pretty straightforward.
I personally don't love making S type annotation, as it's not safe. This also applies to createJSONStorage.

Zustand doesn't seem to infer that despite the storage being provided type arguments <S, Promise<void>>.

If I understand it correctly, yeah, it doesn't distinguish sync storage and async storage.
It's the design choice a long time ago, but there should be a better way if I think of it now.

[kettanaito]

Got it, thanks!

npm errors have defeated me when I was trying to publish the package. I will retry it a bit later when I have a moment. Has to do with the granular tokens rollout, not sure what exactly is wrong as the npm output is 2-screens long with no indicative of what's actually causing the error.

[kettanaito]

2025 Update

If you're looking to persist your Zustand stores in IndexedDB, I've published a community package called zustand-indexeddb. It's the most versatile way to use IndexedDB for store persistence and I hope it will serve your apps well.

npm i zustand-indexeddb

Also check out the FAQ section to find answers to questions like "How is this different from using idb-keyval?" (because it is different, in a good way).

[m7md1alaa]

thank you so much

[wa1one]

There is hardcoded version of db version const openRequest = indexedDB.open(databaseName, 1), how is that gonna be used? One store per db?

[kettanaito]

That's likely an oversight and that version should be removed or the version should be surfaced to the user. Pull requests are welcome!