Update docs and add to changes

Author: robhudson

docs/architecture.rst

@@ -68,9 +68,12 @@ the store ID. This is so that the toolbar can load the collected metrics
 for that particular request.
 
 The history panel allows a user to view the metrics for any request since
-the application was started. The toolbar maintains its state entirely in
-memory for the process running ``runserver``. If the application is
-restarted the toolbar will lose its state.
+the application was started. By default, the toolbar maintains its state
+entirely in memory (``MemoryStore``) for the process running ``runserver``.
+If the application is restarted the toolbar will lose its state. To persist
+data across restarts, configure ``TOOLBAR_STORE_CLASS`` to use
+``DatabaseStore`` or ``CacheStore``. See the
+:ref:`TOOLBAR_STORE_CLASS <TOOLBAR_STORE_CLASS>` configuration option for details.
 
 Problematic Parts
 -----------------

docs/changes.rst

@@ -16,6 +16,12 @@ Pending
   rather than on instantiation.
 * Highlighted the documentation about disabling the browser's caching to
   ensure the latest static assets are used.
+* Added ``debug_toolbar.store.CacheStore`` for storing toolbar data using
+  Django's cache framework. This provides persistence without requiring
+  database migrations, and works with any cache backend (Memcached, Redis,
+  database, file-based, etc.).
+* Added ``CACHE_BACKEND`` and ``CACHE_KEY_PREFIX`` settings to configure the
+  ``CacheStore``.
 
 6.2.0 (2026-01-20)
 ------------------

docs/configuration.rst

@@ -190,22 +190,66 @@ Toolbar options
 
   Available store classes:
 
-  * ``debug_toolbar.store.MemoryStore`` - Stores data in memory
-  * ``debug_toolbar.store.DatabaseStore`` - Stores data in the database
-
-  The DatabaseStore provides persistence and automatically cleans up old
-  entries based on the ``RESULTS_CACHE_SIZE`` setting.
-
-  Note: When using ``DatabaseStore`` migrations are required for
+  * ``debug_toolbar.store.MemoryStore`` - Stores data in memory. This is the
+    default and requires no additional configuration. Data is lost when the
+    server restarts.
+  * ``debug_toolbar.store.DatabaseStore`` - Stores data in the database.
+    Requires running migrations (see below).
+  * ``debug_toolbar.store.CacheStore`` - Stores data using Django's cache
+    framework. Works with any cache backend (Memcached, Redis, database,
+    file-based, etc.). See ``CACHE_BACKEND`` and ``CACHE_KEY_PREFIX`` below
+    for configuration options.
+
+  The ``DatabaseStore`` and ``CacheStore`` both provide persistence across
+  server restarts and automatically clean up old entries based on the
+  ``RESULTS_CACHE_SIZE`` setting.
+
+  Note: When using ``DatabaseStore``, migrations are required for
   the ``debug_toolbar`` app:
 
   .. code-block:: bash
 
       python manage.py migrate debug_toolbar
 
-  For the ``DatabaseStore`` to work properly, you need to run migrations for the
-  ``debug_toolbar`` app. The migrations create the necessary database table to store
-  toolbar data.
+  The toolbar's own cache and SQL operations are automatically hidden from
+  the cache and SQL panels when using ``CacheStore``, so you won't see the
+  toolbar's internal bookkeeping in the collected metrics.
+
+* ``CACHE_BACKEND``
+
+  Default: ``"default"``
+
+  The alias of the Django cache backend to use when ``TOOLBAR_STORE_CLASS``
+  is set to ``debug_toolbar.store.CacheStore``. This should match one of
+  the keys in your :setting:`CACHES` setting.
+
+  Using a dedicated cache backend for the toolbar is recommended in
+  production-like environments to avoid evicting application cache entries:
+
+  .. code-block:: python
+
+      CACHES = {
+          "default": {
+              "BACKEND": "django.core.cache.backends.redis.RedisCache",
+              "LOCATION": "redis://127.0.0.1:6379",
+          },
+          "debug-toolbar": {
+              "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
+          },
+      }
+
+      DEBUG_TOOLBAR_CONFIG = {
+          "TOOLBAR_STORE_CLASS": "debug_toolbar.store.CacheStore",
+          "CACHE_BACKEND": "debug-toolbar",
+      }
+
+* ``CACHE_KEY_PREFIX``
+
+  Default: ``"djdt:"``
+
+  A prefix applied to all cache keys used by the ``CacheStore``. This
+  prevents collisions with other cache entries when sharing a cache
+  backend with the rest of your application.
 
 .. _TOOLBAR_LANGUAGE:
 
@@ -418,12 +462,20 @@ Here's what a slightly customized toolbar configuration might look like::
         'SQL_WARNING_THRESHOLD': 100,   # milliseconds
     }
 
-Here's an example of using a persistent store to keep debug data between server
+Here's an example of using the database store to keep debug data between server
 restarts::
 
     DEBUG_TOOLBAR_CONFIG = {
-        'TOOLBAR_STORE_CLASS': 'debug_toolbar.store.DatabaseStore',
-        'RESULTS_CACHE_SIZE': 100,  # Store up to 100 requests
+        "TOOLBAR_STORE_CLASS": "debug_toolbar.store.DatabaseStore",
+        "RESULTS_CACHE_SIZE": 100,  # Store up to 100 requests
+    }
+
+Here's an example of using the cache store, which provides persistence without
+requiring migrations::
+
+    DEBUG_TOOLBAR_CONFIG = {
+        "TOOLBAR_STORE_CLASS": "debug_toolbar.store.CacheStore",
+        "CACHE_BACKEND": "default",  # Or a dedicated cache alias
     }
 
 Theming support