Show HN: I built a database for AI agents

Kappa90 11 points 10 comments April 07, 2026
github.com · View on Hacker News

Hey HN, I just spent the last few weeks building a database for agents. Over the last year I built PostHog AI, the company's business analyst agent, where we experimented on giving raw SQL access to PostHog databases vs. exposing tools/MCPs. Needless to say, SQL wins. I left PostHog 3 weeks ago to work on side-projects. I wanted to experiment more with SQL+agents. I built an MVP exposing business data through DuckDB + annotated schemas, and ran a benchmark with 11 LLMs (from Kimi 2.5 to Claude Opus 4.6) answering business questions with either 1) per-source MCP access (e.g. one Stripe MCP, one Hubspot MCP) or 2) my annotated SQL layer. My solution consistently reached 2-3x accuracy (correct vs. incorrect answers), using 16-22x less tokens per correct answer, and being 2-3x faster. Benchmark in the repo! The insight is that tool calls/MCPs/raw APIs force the agent to join information in-context. SQL does that natively. What I have today: - 101 connectors (SaaS APIs, databases, file storages) sync to Parquet via dlt, locally or in your S3/GCS/Azure bucket - DuckDB is the query engine — cross-source JOINs across sources work natively, plus guardrails for safe mutations / reverse ETL - After each sync a Claude agent annotates the schema: table descriptions, column docs, PII flags, relationship maps It works with all major agent frameworks (LangChain, CrewAI, LlamaIndex, Pydantic AI, Mastra), and local agents like Claude Code, Cursor, Codex and OpenClaw. I love dinosaurs and the domain was available, so it's called Dinobase. It's not bug free and I'm here to ask for feedback or major holes in the project I can't see, because the results seem almost too good. Thanks!

Discussion Highlights (5 comments)

federiconitidi

Could you give more context on the benchmarks included in the repo?

peterbuch

Nice work. One thinga I'd love to see in the bench mark: a breakdown by question type (aggregations vs. multi-hop joins vs. lookups). My guess is the SQL approach pulls ahead hardest on the join-heavy ones, and showing that explicitly would make the "too good to be true" results feel more grounded. Either way, the token efficiency numbers sounds intruiging.

tosh

Which llm is best at driving DuckDB currently?

c6d6

How does it handle schema drift (eg saas vendor changes a column)? Does the annotation agent mark breaking changes in some way or just describe the current state of the world? With that many connections, you'll hit a bunch of weird edge cases, especially with things like salesforce custom objects.

igrvs

Interesting approach, makes a lot of sense. Looks promising!

Semantic search powered by Rivestack pgvector
3,871 stories · 36,122 chunks indexed