# What is Django `LocMemCache` (Local Memory Cache)?

![Robots’ data storage image](/media/editor_temp/6/62743df3-4837-47d2-b16a-a458240f5629.png)

`LocMemCache` is Django’s **local‑memory cache backend**. If you don’t configure a cache, Django falls back to this local memory cache by default. It’s handy for lightweight apps that don’t need shared memory, or for quickly testing on a development server before setting up Redis.

**Key points**

* **Storage location:** RAM of the currently running **Django process**
* **Scope:** **Per‑process** – not shared outside the process
* **Thread‑safety:** **Thread‑safe**

---

## What problems does it solve?

A cache temporarily holds expensive calculations or queries so they can be reused on subsequent requests.

For example, if you cache a frequently queried value from the database:

* First request: query DB → store result in cache
* Subsequent requests: return immediately from cache (fast)

`LocMemCache` stores this cache **directly in your process’s memory** without any external system like Redis or Memcached.

---

## Core operation details

### 1) It’s a *per‑process* cache (most important)

The Django docs state clearly: the local memory cache is **per‑process**. That means:

* With 4 Gunicorn workers → **4 separate caches**
* With 2 servers → **each server has its own cache**

So caches are not shared across processes or servers.

### 2) It’s *thread‑safe*

The backend is designed to be safe when multiple threads in the same process access it concurrently.

### 3) It disappears on restart

Because it lives only in memory, restarting the process clears the cache.

---

## How to configure it

Add the following to `settings.py` under `CACHES`:

```python
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
        "LOCATION": "unique-snowflake",
    }
}
```

The example from the official docs uses this format; `LOCATION` simply identifies the cache instance.

---

## Advantages

* **Minimal setup** – no external cache server needed
* **Fast** – access to the same process’s memory incurs very low latency
* **Convenient for development/testing** – great for adding caching concepts without external dependencies

---

## Drawbacks and cautions

* **Cache fragmentation in multi‑process/multi‑server setups** – you may see “cache not working” because each process has its own cache
* **Unpredictable in production** – traffic spread across many processes can lower hit rates
* **Not recommended for session storage** – Django’s session docs warn that local memory caches don’t persist long enough and aren’t safe across multiple processes

---

## When is it appropriate to use?

* Local development environments
* Single‑process deployments (or when cache sharing isn’t required)
* Feature validation/testing with minimal external dependencies

If you need **the same cache across multiple processes or servers**, it’s usually better to use a shared cache like Redis or Memcached.