# Agent Storage (/features/storage)



Agent state has to remain available across conversations, restarts, and replicas. Agents, teams, workflows, and AgentOS share a `db` interface for sessions, memory, learnings, knowledge metadata, traces, schedules, approvals, evaluations, and metrics.

The `db` parameter accepts JSON file, embedded, relational, document, key-value, and distributed backends. Backend capabilities differ: session storage support does not imply support for every AgentOS domain. Check the provider guide before enabling components, scheduling, or durable jobs.

```python
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)
```

By default, AgentOS attempts startup provisioning for discovered backends that implement it. Set `auto_provision_dbs=False` to skip this startup pass; individual backend operations may still create tables lazily. Provision the required schema before serving traffic when you manage migrations yourself.

## What gets stored [#what-gets-stored]

| Table                                                               | Holds                                                                              |
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `agno_sessions`                                                     | Session metadata and state keyed by `session_id`, with an optional `user_id` owner |
| `agno_runs`                                                         | Per-run records linked to sessions on backends using normalized run storage        |
| `agno_memories`                                                     | User memories the agent decides to keep                                            |
| `agno_learnings`                                                    | Learnings captured from runs                                                       |
| `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                                                           |
| `agno_components`, `agno_component_configs`, `agno_component_links` | Component identities, versioned configurations, and dependencies                   |
| `agno_service_accounts`                                             | Service-account metadata and token verification data                               |
| `agno_jobs`                                                         | Accepted jobs when durable queueing is configured                                  |

Backend-specific table and collection names may vary. With a custom session table name, the default runs table is `<session_table>_runs`. Session IDs must be unique within the session store; `user_id` is not part of a composite session primary key.

## Pick a backend [#pick-a-backend]

Most tutorials use `PostgresDb`. Pair it with `PgVector` when you want relational data and embeddings on the same Postgres instance.

| Backend                                                     | When to use                                                           |
| ----------------------------------------------------------- | --------------------------------------------------------------------- |
| [`PostgresDb`](/database/providers/postgres/overview)       | Production runtime state; pair with `PgVector` for embeddings         |
| [`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) | Existing SingleStore infrastructure and high-throughput runtime state |
| [`RedisDb`](/database/providers/redis/overview)             | Existing Redis infrastructure and high-throughput key-value access    |
| [`ValkeyDb`](/database/providers/valkey/overview)           | Existing Valkey infrastructure and high-throughput key-value access   |
| [`DynamoDb`](/database/providers/dynamodb/overview)         | AWS-native, serverless                                                |
| [`FirestoreDb`](/database/providers/firestore/overview)     | GCP-native, serverless                                                |
| [`JsonDb`](/database/providers/json/overview)               | Local JSON file storage                                               |
| [`GcsJsonDb`](/database/providers/gcs/overview)             | JSON-backed records in Google 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 [#vector-storage]

Knowledge uses a vector store for embedding search.

```python
from agno.knowledge import Knowledge
from agno.vectordb.pgvector import PgVector
from agno.vectordb.search import SearchType

agent = Agent(
    db=db,
    knowledge=Knowledge(
        vector_db=PgVector(
            table_name="my_kb",
            db_url=DB_URL,
            search_type=SearchType.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).

For production deployments already using Postgres, pair `PostgresDb` with `PgVector` to keep runtime state and hybrid search in one Postgres service.

## Splitting concerns across databases [#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
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 include separate tenant databases, a high-traffic agent on its own engine, or one workflow's session history on a different backend. Database-level tenant isolation also requires separate credentials and grants.

## File and blob storage [#file-and-blob-storage]

Store generated images, audio, and large PDFs in object storage, then reference their paths in `agno_knowledge` or `agno_sessions`.

## Developer Resources [#developer-resources]

* [Database overview](/database/overview)
* [Vector stores](/knowledge/vector-stores)
* [Database migrations](/agent-os/usage/database-migrations)