-
Notifications
You must be signed in to change notification settings - Fork 203
Decoupling runtime state,knowldege db and the data db #12
Description
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:
- Runtime state – agent runs, chat history, scheduler (via PostgresDb).
- Knowledge base – vectors (PgVector) and knowledge/learnings contents (Postgres tables).
- 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