> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bindai.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 04.2 providers

# Memory Providers

BindAI separates **memory management** from **memory storage** through memory providers.

A memory provider is responsible for saving, loading, updating, and deleting conversation history or other persistent information.

Because providers follow a common interface, applications can switch storage backends without changing agent code.

***

# Why Providers?

Different applications have different requirements.

For example:

* prototypes may only need temporary memory
* production systems often require persistent storage
* distributed deployments may use centralized databases
* AI assistants may combine multiple memory systems

Memory providers make these scenarios possible while keeping the agent API consistent.

***

# Provider Architecture

The architecture is intentionally simple.

```text id="l8q1tz" theme={null}
Agent

↓

Memory

↓

Memory Provider

↓

Storage
```

The agent interacts only with the Memory object.

The Memory object delegates storage operations to the configured provider.

***

# Available Providers

BindAI currently includes:

* In-Memory Provider

Additional providers may include:

* SQLite
* PostgreSQL
* Redis
* MongoDB
* Vector Databases
* Cloud Storage

The provider interface is designed so new implementations can be added without modifying existing agents.

***

# In-Memory Provider

The default provider stores everything in memory.

```python id="sj3w6f" theme={null}
from bindai_memory import (
    Memory,
    InMemoryProvider,
)

memory = Memory(
    InMemoryProvider(),
)
```

This provider is ideal for:

* development
* testing
* examples
* temporary conversations

Data is lost when the application exits.

***

# Using a Provider

Attach the memory instance to an agent.

```python id="b6n4wa" theme={null}
agent.use_memory(
    memory,
)
```

Once configured, loading and saving occur automatically during execution.

***

# Provider Responsibilities

Every provider is responsible for operations such as:

* storing messages
* retrieving messages
* clearing memory
* updating stored data
* managing conversation state

The agent never needs to know how the provider performs these tasks.

***

# Persistent Providers

Persistent providers keep data after the application stops.

Typical workflow:

```text id="t9c8pk" theme={null}
Conversation

↓

Memory Provider

↓

Database

↓

Restart Application

↓

Conversation Restored
```

This allows assistants to maintain long-term conversations across sessions.

***

# Distributed Systems

Providers also enable multiple application instances to share memory.

```text id="h4m2ey" theme={null}
Agent A

↓

Shared Database

↑

Agent B
```

Both agents access the same stored conversation.

***

# Session Isolation

Most providers organize memory by session.

Example:

```text id="cw0lvd" theme={null}
Session A

↓

Conversation A

Session B

↓

Conversation B
```

Keeping conversations isolated prevents unrelated sessions from mixing together.

***

# Performance

Different providers offer different performance characteristics.

| Provider        | Best For                 |
| --------------- | ------------------------ |
| In-Memory       | Development and testing  |
| SQLite          | Small local applications |
| PostgreSQL      | Production systems       |
| Redis           | Fast distributed memory  |
| Vector Database | Semantic retrieval       |

The appropriate provider depends on application requirements.

***

# Choosing a Provider

General recommendations:

**In-Memory**

* tutorials
* local development
* examples

**Database Provider**

* production deployments
* persistent conversations
* multi-user systems

**Redis**

* distributed applications
* shared state
* high performance

**Vector Provider**

* semantic memory
* similarity search
* long-term retrieval

***

# Swapping Providers

Because all providers implement the same interface, changing storage usually requires only replacing the provider.

Example:

```python id="e5x7kb" theme={null}
memory = Memory(
    SomeOtherProvider(),
)
```

The rest of the application remains unchanged.

***

# Best Practices

* Use In-Memory during development.
* Use persistent providers for production.
* Isolate conversations by session.
* Avoid storing unnecessary information.
* Consider backup and retention strategies.
* Select a provider that matches expected scale.

***

# Summary

Memory providers determine **where** and **how** BindAI stores conversational information.

The provider abstraction allows applications to evolve from simple local prototypes to large distributed production systems without changing the agent programming model.