Loopy

Multi-tenant agentic platform with two embedded SQL engines. SQLite for memory and state, chDB (embedded ClickHouse) for analytics.

Almost every agentic data platform I’ve seen reaches out to an external database on every query. Vector store for memory, separate warehouse for analytics, another service for config. It works fine until it doesn’t, and then you’re debugging network timeouts between three different infrastructure pieces.

Loopy takes the opposite approach. Everything runs embedded: SQLite for transactional work (session state, memory records, config, audit log), chDB (embedded ClickHouse) for analytics (aggregations, CSV/Parquet ingestion, cross-session data). No servers to manage per tenant, no network hops between the agent and its data.

Tenants upload their data, ask questions in plain English, and get SQL-backed answers. Sub-second response times because the query never leaves the process.

Why two engines

Agents have two genuinely different storage patterns and one engine handles both badly.

SQLite is excellent at OLTP: fast on point lookups, cheap to keep one file per tenant, WAL mode handles concurrent reads without drama. It falls apart when you run aggregations over millions of rows.

chDB (embedded ClickHouse) is the opposite. Blazing fast on analytical queries, native text_to_sql support, Parquet and CSV ingestion built in. But you wouldn’t use it as your session store.

Both speak SQL, so I wrote a single NL-to-SQL router that classifies query intent and dispatches to the right engine. From the agent’s perspective there’s just one query interface.

How it’s structured

Each tenant gets their own SQLite file and their own chDB database (isolated via CREATE DATABASE tenant_{id} within a shared session, since chDB only supports one session per process). Physical isolation without the complexity of row-level security.

Memory is split into three types: episodic memory in SQLite (conversation history, FTS5 search, decay so stale memories get pruned), semantic memory in chDB (domain knowledge materialized from the tenant’s connected data), and procedural memory in SQLite (stored SQL templates and reusable query patterns).

The agent is built on Agno with composable skills: chdb_analytics, sqlite_memory, data_ingestion, schema_explorer, query_learning. Tenants can enable or disable skills per request.

Where it’s at

266 tests across 7 phases. Core pipeline, memory system, and all skills are working. Still to do: connector coverage for S3, Postgres, BigQuery; an MCP server so Loopy works as a tool inside Cursor and Claude Desktop; and a skill marketplace.

The ClickHouse Bangalore Meetup talk on self-contained data agents is what got me started on the architecture. I wrote up that pattern in more detail in this blog post.

If you want to help

I’m looking for people who’ve built Postgres or S3 connectors, or who’ve shipped an MCP server. Either of those would be a big help right now. Reach out if that’s you.