Skip to content

Decoupling runtime state,knowldege db and the data db #12

@KaunilD

Description

@KaunilD

Hi @ashpreetbedi,

First of all, thanks for Agno - it’s been great to use.

I’d like to raise a feature/design question: decoupling the database used for agent/knowledge storage from the database the agent queries.
Current behavior (as I understand it)

Today, a single Postgres instance is often used for:

  1. Runtime state – agent runs, chat history, scheduler (via PostgresDb).
  2. Knowledge base – vectors (PgVector) and knowledge/learnings contents (Postgres tables).
  3. Data DB – the database that tools like SQLTools run queries against (e.g. analytics tables).

So agent state, knowledge, and “user data” all live in (or go through) Postgres.

What I’m proposing:

Being able to keep Postgres for (1) and (2) while using a different database for (3). Concretely, I’d like to point the agent at a ClickHouse (or other) database for analytics, while Agno’s own state and knowledge stay on Postgres (or another supported backend).

Why

Many analytics workloads already live in ClickHouse (or other OLAP stores).

Keeping “where the agent stores its state/knowledge” separate from “where the agent runs SQL” would make it easier to adopt Agno in those environments without moving data to Postgres. What are your thoughts on supporting this kind of split (e.g. a dedicated “data” / “query” DB connection separate from the agent/knowledge DB)? Is something like this already on the roadmap, or would you be open to a design/PR in this direction?

Thanks again for Agno.
Kaunil D

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions