> ## Documentation Index
> Fetch the complete documentation index at: https://agno-v2-service-account.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Storage

> Store sessions, memory, knowledge, traces in any database backend.

Agents can persist every data point they generate and use in a database, set by the `db` param. We can store sessions, memory, knowledge, traces, schedules, approvals, learnings and even usage metrics.

The primitives (agents, teams, workflows) and the AgentOS accept a `db` param. Pick from JSON files (local or cloud), embedded (SQLite), relational (Postgres, MySQL), document (MongoDB, Firestore), key-value (Redis, DynamoDB), or distributed (SingleStore).

```python theme={null}
from agno.db.postgres import PostgresDb
from agno.os import AgentOS

db = PostgresDb(db_url="postgresql+psycopg://user:pass@host:5432/agno")

agent_os = AgentOS(agents=[agent], db=db)
```

When we set the `db` param, AgentOS creates the tables and indexes on first boot.

## What gets stored

| Table                                  | Holds                                                            |
| -------------------------------------- | ---------------------------------------------------------------- |
| `agno_sessions`                        | Conversation history per `(user_id, session_id)`                 |
| `agno_memories`                        | User memories the agent decides to keep                          |
| `agno_knowledge`                       | Knowledge content metadata (embeddings live in the vector store) |
| `agno_traces`, `agno_spans`            | OpenTelemetry traces                                             |
| `agno_approvals`                       | Pending and resolved HITL requests                               |
| `agno_schedules`, `agno_schedule_runs` | Cron jobs                                                        |
| `agno_metrics`, `agno_eval_runs`       | Metrics and eval results                                         |

* Backend-specific names may vary.
* Schema changes are generally additive.

## Pick a backend

`PostgresDb` is the default for most tutorials and the recommended production database. It pairs well with `PgVector` to keep relational data and embeddings on the same engine.

| Backend                                                     | When to use                                            |
| ----------------------------------------------------------- | ------------------------------------------------------ |
| [`PostgresDb`](/database/providers/postgres/overview)       | Production. Vector + relational on one box.            |
| [`SqliteDb`](/database/providers/sqlite/overview)           | Local dev, single-user demos, edge deployments         |
| [`MongoDb`](/database/providers/mongo/overview)             | Already on Mongo                                       |
| [`MySQLDb`](/database/providers/mysql/overview)             | Already on MySQL                                       |
| [`SingleStoreDb`](/database/providers/singlestore/overview) | Vector + analytics on one engine, high-throughput      |
| [`RedisDb`](/database/providers/redis/overview)             | Cache-friendly, ephemeral sessions                     |
| [`DynamoDb`](/database/providers/dynamodb/overview)         | AWS-native, serverless                                 |
| [`FirestoreDb`](/database/providers/firestore/overview)     | GCP-native, serverless                                 |
| [`GcsJsonDb`](/database/providers/gcs/overview)             | Cheap cold storage, knowledge as JSON in Cloud Storage |
| [`InMemoryDb`](/database/providers/in-memory/overview)      | Tests, ephemeral demos                                 |

Postgres-compatible managed services like [Neon](/database/providers/neon/overview) and [Supabase](/database/providers/supabase/overview) work with `PostgresDb` directly. Point `db_url` at the managed instance. Async variants (`AsyncPostgresDb`, `AsyncSqliteDb`, `AsyncMongoDb`, `AsyncMySQLDb`) are documented under [Database](/database/overview).

## Vector storage

Knowledge needs a vector store and Agno supports 15+ vector databases out of the box.

```python theme={null}
from agno.knowledge import Knowledge
from agno.vectordb.pgvector import PgVector

agent = Agent(
    db=db,
    knowledge=Knowledge(
        vector_db=PgVector(
            table_name="my_kb",
            db_url=DB_URL,
            search_type="hybrid",   # vector + full-text search
        ),
    ),
)
```

Other options: LanceDB, Qdrant, Weaviate, Pinecone, Chroma, MongoDB Atlas, Cosmos, Cassandra, ClickHouse, SurrealDB, Milvus. See [Vector Stores](/knowledge/vector-stores/index).

For most production AgentOS deployments, **PgVector + PostgresDb on the same Postgres** is the right default. One database, hybrid search, transactional reads, no extra service to operate.

## Splitting concerns across databases

Every agent, team, and workflow can take its own `db`, overriding the AgentOS default.

Use the AgentOS `db` for shared state and hand individual components a separate database when they need isolation:

```python theme={null}
shared_db = PostgresDb(db_url="postgresql+psycopg://shared/...")
tenant_db = PostgresDb(db_url="postgresql+psycopg://tenant-a/...")

tenant_agent = Agent(name="tenant-a-support", db=tenant_db)
internal_agent = Agent(name="ops", db=shared_db)

agent_os = AgentOS(
    agents=[tenant_agent, internal_agent],
    db=shared_db,
)
```

Common splits: per-tenant DBs for strict isolation, a high-traffic agent on its own engine, or routing one workflow's session history to a cheaper backend.

## File and blob storage

For media that doesn't belong in the relational store (generated images, audio, large PDFs), store them in object storage and reference paths in `agno_knowledge` or `agno_sessions`.