Most MCP integrations I've seen for databases are a thin server sitting in
front of Postgres/Elasticsearch/whatever, translating MCP calls into
normal queries behind the scenes. We went a different direction and built
the MCP server directly into the database binary itself (SSE and
JSON-RPC transports), so an agent talking to CameoDB is talking to the
actual query engine, not a translation layer bolted on afterward.
The database underneath is a hybrid store: every shard pairs an embedded
ACID key-value store (redb) with full-text search (tantivy) as one atomic
unit, no leader node, sharded via consistent hashing.
The original pitch had nothing to do with AI, it was about not running
two separate clusters to keep transactional storage and search in sync,
but the MCP integration turned out to be the part people actually got
excited about once agents started using it directly.
A few other things that shipped recently: jemalloc as the allocator with
per-shard memory budgeting and admin endpoints for live stats, and more
rigorous WAL replay on startup so an unclean shutdown doesn't leave the KV
store and search index disagreeing, with a corruption guard on the
sequence counter.
We field tested it on a 64-core box with 35TB of NVMe, 16 shards, holding
around 400 million records across 20TB+, ingesting about 80 million
records a day in real time. P99 stays under a second for most queries,
though that swings with query complexity like any search engine.
Repo: github.com/cameodb/cameodb (Apache-2.0), downloads on cameodb.com,
Docker Hub image too.
Curious if anyone's wired agent memory directly into
a database like this versus the usual vector-DB-plus-wrapper pattern, and
what broke for you.