OceanBase seekdb 1.3.0 Released: 22x Performance Gain, Jitter-Free P99

Posted on In Views: Word count in article: 1.4k Reading time ≈ 5 mins.
OceanBase seekdb 1.3.0 is here, introducing an asynchronous index model based on Change Stream that decouples writes from index building. In streaming scenarios it boosts throughput by roughly 22x with virtually no P99 jitter under concurrency, and adds capabilities such as Fork/Diff & Merge for vector columns.

🚀 Want to experience this 22x performance leap firsthand? seekdb is open source on GitHub—come try it at https://github.com/oceanbase/seekdb! Fresh features like the asynchronous index and Fork Table are all in place, just waiting for you to explore.

OceanBase seekdb 1.3.0: a major release themed around “broad platform coverage and high performance.”

What’s new in this release:

  • Introduces an asynchronous index model built on the Change Stream incremental framework, fully decoupling write operations from index building
  • Improves both retrieval performance and write throughput for AI Agent workloads—in streaming scenarios, throughput is roughly 22x higher than in synchronous mode.
  • Diff & Merge now supports vector columns
  • Fork Table / Fork Database is fully aligned with the asynchronous index
  • Enhanced multi-version data management

For the full changelog, see: GitHub Release v1.3.0

This article is a technical walkthrough of OceanBase seekdb 1.3.0. We start from real Agent workload scenarios, combine third-party test data, and explain in detail the architectural design trade-offs and solutions in this release. If you’re currently choosing a database for your Agent, we hope this article helps you avoid a pitfall.

1. Why Agents Need a Vector Database Built for Streaming Workloads

An Agent’s real workload is a streaming workload—and most vector databases weren’t designed for it.

1.1 An Agent’s Workload Looks Nothing Like a Benchmark

If you’re choosing a vector database for your Agent, chances are you’re looking at ann-benchmarks or the performance comparisons each vendor publishes. Those tests run a workload like this: bulk-import all the data, build the index, then run read-only queries.

That’s not an Agent’s workload. An Agent’s real workload looks like this:

1
2
3
for step in agent.run():
    memory.write(step.observation)        # continuous writes
    relevant = memory.search(step.query)  # retrieval milliseconds later

Writes and retrievals happen at the same time, milliseconds apart, and concurrently. This kind of workload has a name—the streaming workload.

VectorDBBench has a StreamingPerformanceCase designed exactly for this: continuous writes at a fixed rate plus concurrent queries, just like an Agent in production.

VectorDBBench is maintained by Zilliz (the company behind Milvus) and is a third-party open-source benchmark framework. We used it to test 6 mainstream vector databases.

1.2 The Overlooked Metric: How Much Does P99 Grow Under Concurrency?

Test conditions: the Cohere 10M dataset (768 dimensions), 16 vCPU / 64 GiB, unified HNSW index parameters (M=16 / ef_construction=256 / ef_search=200), continuous writes at 500 rows/sec.

Streaming workload performance comparison of six vector databases

Most people only look at QPS and serial latency in a benchmark. But an Agent doesn’t run single-threaded in production. What really determines your SLA is the concurrent P99—and how many times it grows as concurrency increases.

Look at the “P99 Jitter” group in the chart:

  • ES: 10.3x—serial P99 is only 5.2ms (faster than OceanBase seekdb), but as soon as concurrency kicks in it jumps to 53.6ms
  • Vector database A: 9.7x—serial 15.9ms, soaring straight to 153.6ms under concurrency
  • OceanBase seekdb: 1.1x—from 19.7ms to 21.7ms, barely moving

This isn’t a parameter-tuning problem—it’s an architecture problem. The next section explains in detail.

※ Full test scripts and configuration: github.com/oceanbase/vdb-streambench. PRs adding more products are welcome.

1.3 Why P99 Blows Up Under Streaming Workloads

Vector databases A, B, and D perform excellently in the scenarios they’re good at (bulk import + read-only queries)—that’s precisely what they were designed for. But streaming writes expose a structural problem: they continuously produce new segments. At query time you have to fan out to N segments, run knn on each, and merge the results. While barely manageable in single-threaded scenarios, it becomes unmanageable under concurrency: as soon as concurrency rises, N segments × M query threads fight over the CPU, and P99 skyrockets.

For most vector databases, the number of index segments balloons with streaming writes, and contention from concurrent queries gets worse and worse. The number of indexes in OceanBase seekdb is fixed (always just two), so it doesn’t.

1.4 How seekdb 1.3.0 Keeps P99 Flat

Specifically, OceanBase seekdb 1.3.0 designs two mechanisms for streaming workloads:

Mechanism 1: The Write Path Never Touches the Index

After a transaction commits, it just writes the redo log and returns. A separate Change Stream pipeline asynchronously consumes the redo log in the background, writing vectors into an in-memory delta HNSW index. Writes and index building are fully decoupled at the physical level—writes are never blocked by index construction.

Mechanism 2: The Query Path Always Goes Through Exactly Two Indexes

OceanBase seekdb maintains one delta HNSW (the incremental layer that receives new writes) and one snapshot HNSW (the main bulk layer), much like the tiered approach of an LSM-Tree. At query time it runs one knn search against each of the two indexes and merges the results—no matter how much data is written, the index count doesn’t balloon and concurrent queries don’t contend.

2. Beyond Speed: Capabilities Built for Agents

2.1 An Agent Needs an Undo Button: Fork & Copy-on-Write

That’s it for performance. But anyone who’s built an Agent knows there’s another pain point: an Agent needs to make exploratory changes to data (modify memory, run experiments, maybe corrupt a table), and you need a safe sandbox and a rollback mechanism.

Most vector databases have no such concept. OceanBase seekdb implements Copy-on-Write directly in the kernel:

1
2
3
4
5
6
7
8
9
10
11
12
13
-- Second-level snapshot, no data copying
FORK DATABASE agent_state TO sandbox_42;

-- The Agent can do whatever it wants in the sandbox
USE sandbox_42;
INSERT INTO memory(embedding, content)
VALUES('[0.1,...]', 'new observation');

-- Exploration succeeded → merge back into the mainline
MERGE TABLE sandbox_42.memory INTO agent_state.memory STRATEGY THEIRS;

-- Exploration failed → throw it away, the mainline is unaffected
DROP DATABASE sandbox_42;

This is kernel-level COW, not application-layer snapshot/restore. A fork completes in seconds without copying data, and each sandbox is a fully writable database (schema, vector indexes, and auto-increment columns all work normally). Three conflict strategies (FAIL / THEIRS / OURS) let you precisely control how much of the Agent’s changes can be trusted. Both FORK DATABASE and FORK TABLE granularities are supported.

2.2 Hybrid Search in a Single SQL Statement

An Agent’s retrieval usually isn’t pure vector similarity. You might need to filter by author and time range simultaneously, plus a full-text match. In OceanBase seekdb, that’s a single SQL statement:

1
2
3
4
5
6
SELECT id, title, l2_distance(emb, '[0.12,0.34,...]') AS dist
FROM docs
WHERE MATCH(content) AGAINST('quarterly report')
  AND author_id = 42
  AND created_at > '2026-01-01'
ORDER BY dist APPROXIMATE LIMIT 10;

Vector + full-text + scalar filtering are pushed down within the same execution plan, with no need to stitch together multiple query results on the client side. It’s fully MySQL-protocol compatible, so LangChain / LlamaIndex / Dify / any MySQL client connects directly.

3. Get Started

3.1 Try It in 30 Seconds

1
pip install -U pyseekdb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import pyseekdb
client = pyseekdb.Client(path="./agent_state.db")
memory = client.get_or_create_collection(name="episodic")

memory.upsert(ids=["1", "2", "3"], documents=[
    "user prefers dark mode",
    "user speaks English and Chinese",
    "user timezone is UTC+8",
])
memory.refresh_index()
results = memory.query(query_texts="ui preferences?", n_results=1)
print(results["documents"])

memory.upsert(ids=["4"], documents=["user saw pricing page 3 times today"])
memory.refresh_index()
results = memory.query(query_texts="purchase intent signals", n_results=1)
print(results["documents"])

No server, no schema—the embedded mode runs in-process.

3.2 About OceanBase seekdb

OceanBase seekdb is fully open source (Apache 2.0), developed by the OceanBase team. You may already be using OceanBase—it runs in production at companies like Alipay, Taobao, Didi, and Xiaomi.

OceanBase seekdb inherits the same storage engine and SQL executor, focusing on vector + relational hybrid workloads for Agent scenarios. In just half a year of being open source it has gathered 2,500+ GitHub stars, and mainstream frameworks such as LangChain / LlamaIndex / Dify / Coze have all integrated it.

If you’re choosing a database for your Agent—spend 30 seconds running the demo above.

⭐ github.com/oceanbase/seekdb — a star helps more people discover this project and gives us the motivation to keep investing.

Run into a problem or want to discuss your Agent scenario: GitHub Issues · GitHub Discussions