oceanbase/seekdb

seekdb is worth a look if you are building agent memory or retrieval and are tired of stitching an OLTP store, a vector index, and a search engine together with client-side glue code. It is a bigger commitment than a pip-install demo suggests, and the embedded SDK path is the cheapest way to form an opinion.

The problem

A developer building agent memory typically wants to write a record, embed it, and find it again a second later by combining semantic similarity, keyword matching and metadata filters. The usual setup spreads those jobs across separate systems: a transactional database for agent state, a vector store for embeddings, and a search engine for text. Keeping them consistent means background sync jobs, and the final ranking is merged in application code. seekdb changes the step where results are combined: vector distance, MATCH ... AGAINST full-text matching and ordinary scalar predicates are pushed into one SQL execution plan, so the application issues one query and gets one ordered result set project instructions.

What's different

The notable architectural choice is an async index pipeline the README calls Change Stream. Commits return before index construction finishes, and the redo log is consumed to update a two-level HNSW index with an incremental and a snapshot layer, so newly written vectors are searchable soon after the write. For agent workloads that write constantly and read moments later, that decoupling is the part worth evaluating. The trade-off is an index that tracks the log asynchronously, so understanding the freshness you actually get under load is a real question, not something the default demo answers.

The second distinctive piece is copy-on-write sandboxing: FORK DATABASE creates a snapshot in seconds without copying data, an agent can write or break tables freely, and MERGE TABLE accepts work back with FAIL/THEIRS/OURS strategies while DROP DATABASE discards it. This is kernel-level rather than application-layer save/restore. A fork is a convenience for experimentation, not a backup guarantee or a statement about how long a snapshot persists. Being MySQL-compatible and ACID means the existing SQL tooling and drivers mostly apply project instructions. The README also publishes a benchmark image claiming 10.7x Milvus and 3.2x Elasticsearch QPS, with a reproduction repository benchmark harness; treat that as the vendor's claim until you run it against your own data.

Who should try it

Good fit: a team building agent state, RAG or hybrid search that already values SQL and MySQL semantics and wants one engine instead of three. The embedded Python, Node.js and Go paths embedded SDK options let you evaluate locally without standing up a service. Poor fit: teams already running a well-tuned vector database and search stack with no consistency pain, or those who need a broad set of mature operational tooling and community answers on day one. If your retrieval is pure vector and never needs text or filters, the all-in-one pitch buys you less.

Requirements and limitations

Installation is the easy part, with the Python path requiring Python 3.11+ and pylibseekdb plus a MySQL driver Python SDK package. The harder part is ongoing: you inherit a C++ database engine from the OceanBase lineage, and operations around upgrades, the async indexing pipeline, and COW fork and merge semantics are things your team has to understand, not merely install. The README names three deployment shapes (embedded, single-node server, distributed cluster); the operational burden varies enormously across them.

Benchmark figures come from the project's own harness and hardware, so performance in your write-heavy agent loop needs your own measurement. The documentation excerpts supplied here do not pin down index-freshness latency targets or long-term snapshot behaviour; those are the unknowns to resolve before production dependence.

HotRepo's take

HotRepo's dated history is thin: 3,197 stars and a single daily-board appearance on 2026-10-28 with +6 stars that day, on a repository created 2025-10-21 project page. With one snapshot there is no basis to judge whether interest is sustained or fading. The reasonable next check is the benchmark reproduction repo and your own write-then-search latency test, not the star count.