ExpeditedProjects/hutchdb

A database for AI agents. No schema, SQL, or structure required.
A structured workspace that Claude Code, Codex, Cursor, Hermes, Claw, Grokbot, and other MCP clients can read and update together. Open source.
 
 
 
## What is HutchDB?
HutchDB Core is a headless, single-user MCP server that gives every agent you run the same durable, structured data. Connect Claude Code, Codex, Cursor, VS Code, or another MCP client and they can store, query, and update shared collections of records across sessions.
Collections use schema-optional Postgres JSONB with full-text search, optional validation, and view definitions. There is no dashboard, no login screen, and no OAuth ceremony — just an MCP endpoint and a Postgres database you control.
This repo is the OSS engine. If you want people and agents working from the same visual workspace, HutchDB Cloud adds web views, published pages, social login, and organization sharing. See Core vs Cloud below.
## What can you use it for?
The default home for agent working data is a markdown file: a TODO.md, a notes directory, a memory file full of prose. That works for one agent taking notes to itself. It breaks down the moment you want to filter ("open bugs above severity 2"), aggregate ("pipeline value by stage"), or have two agents update the same list without overwriting each other.
HutchDB holds the same information as real records: individually addressable, queryable, and safe for multiple agents to read and update at once. That makes it fit anywhere an agent produces or uses structured data that needs to outlast one chat. Some patterns people run on it:
Research that accumulates. Customer interviews, competitor teardowns, scraped listings, literature reviews. Each session adds records to a collection; any later session can query the whole set.
> "Save these five competitor pricing pages to competitor-pricing, then tell me who changed since last month."
Trackers you'd otherwise keep in a spreadsheet. Bug reports, content calendars, job applications, inventory, reading lists. The difference from a spreadsheet: your agents can query and update the records mid-task.
> "Log this bug to bug-reports with severity high, then list everything still open."
Pipelines with handoffs between agents. One agent collects records, another processes them, a third reports on the results. A status field on each record marks where it is in the pipeline, so nothing gets copied between tools.
> "Pull every leads record with status new, enrich each one, and set its status to ready-for-outreach."
Working state for long-running projects. Decisions, open questions, and backlog items stay queryable after the context window closes. A new session starts by asking what came before instead of being re-briefed.
> "What did we decide about the pricing page last week, and what's still unresolved?"
Repeatable playbooks. Store the instructions, inputs, and current status for recurring jobs (weekly reports, release checklists, content production) so any agent can pick one up and run it.
> "Run the weekly-metrics playbook and store the results in weekly-reports."
None of this needs schema design up front: collections auto-create on the first write and records are arbitrary JSON. Start with "save this to HutchDB," then query the same records from any connected agent.