SeekDB

AI agents that keep working memory in a database run into a specific pattern that most stores handle badly: they write constantly and read back almost immediately, while also needing to mix semantic similarity, keyword matching, and structured filters in the same lookup. Traditional vector stores and relational databases tend to spike on tail latency when writes and searches compete, and they force teams to bolt together a vector engine, a full-text index, and a SQL database. SeekDB, built by the OceanBase team, is a MySQL-compatible database that targets exactly this workload. It combines ACID relational storage with hybrid vector, full-text, and scalar search in a single SQL query, and adds a copy-on-write sandbox primitive aimed at agents that need to try things and roll back.

SeekDB's design centers on keeping freshly written data immediately searchable without latency spikes. An asynchronous indexing pipeline the project calls Change Stream decouples write commits from index building, and a two-level HNSW vector index, one incremental and one snapshot, makes new vectors queryable right away. The more distinctive feature is FORK/MERGE: copy-on-write sandboxes that snapshot the database in seconds without duplicating data, letting an agent branch off, experiment, then either merge changes back or discard them. Hybrid search runs vector similarity, full-text matching, and scalar filtering in one statement, avoiding client-side result merging. Because it speaks the MySQL protocol, existing ORMs, clients, and GUIs work unchanged, and it can run embedded via pip, as a standalone server, or as an OceanBase cluster node.

The clearest fit is multi-agent and planning systems that need durable, queryable memory with branching state. An agent that speculatively tries a strategy can fork the store, write its hypothetical changes, evaluate the outcome, and merge or throw it away without polluting shared memory, which is awkward to build on a conventional database. Beyond that, SeekDB suits RAG and enterprise question-answering, semantic search across mixed data, AI-assisted code search, and edge or on-device scenarios where a single embedded engine is simpler than running separate vector and SQL services. The MySQL compatibility lowers adoption friction for teams already comfortable with that ecosystem, and integrations with LangChain, LlamaIndex, and Dify are documented, so it can slot into existing agent and retrieval pipelines without a custom client.

The caveats are real and worth weighing. The headline performance figures, including the claim of roughly 10.7x Milvus throughput and 3.2x Elasticsearch, are the project's own benchmarks with no independent reproduction, so they should be read as vendor claims rather than settled results. The repository shows a high open-issue count relative to its star count, which typically signals early rough edges and an API that is still moving. The core is roughly 97 percent C++, which makes debugging and contribution harder for the Python and JavaScript developers who make up much of the agent-building audience, even with the Python bindings. The FORK/MERGE primitive is genuinely novel, but novelty also means fewer battle-tested patterns, less community knowledge, and a storage format that may still change between releases.

Against Weaviate and Milvus, SeekDB trades their maturity and large operational track record for two things those tools do not offer cleanly: a single SQL surface over relational, vector, and full-text data, and the FORK/MERGE branching model. If you are building a multi-agent system that needs durable memory it can speculatively branch and roll back, SeekDB is worth a serious prototype, and the embedded pip install makes that cheap to try. For production RAG that needs proven stability, predictable upgrades, and a wide pool of operational experience, the established engines remain the safer choice today. The honest read is promising and unusually well-motivated, but still early: adopt it where its branching memory model is the point, and wait where you mainly need a dependable vector index.