MatrixOne

A MySQL-compatible distributed database from MatrixOrigin that describes itself as HTAP: transactions, analytics, full-text search and vector search (IVF and HNSW indexes) in one engine. Go, Apache-2.0, ~2.0k★ and 324 forks, created 2021, v4.2.4 released 2026-09-17 (GitHub API, 2026-09-23). Arrived by Telegram. Read from the README and from the team's own paper, Version Control System for Data with MatrixOne (Gou, Tian, Wang, Deng, Xu; arXiv 2604.03927, 5 April 2026), extracted from the PDF.

Tier T1 for the architecture and the version-control design: the builders describing their own system, checkable against the source. The benchmark figures below are the maker's own runs against a SQL baseline the maker wrote, which this corpus reads as T3, and they are flagged where they appear.

Why it lives here

The spoke's boundary rule pages an HTAP store where its centre of gravity sits. For MatrixOne that is the transactional side: it is sold as a drop-in MySQL replacement, and the paper's version-control design depends on primary keys, MVCC and atomic commits. Its analytical half is cross-linked to ../analytical-databases-wiki rather than paged there.

Architecture (from the paper)

Three kinds of node, with storage kept off all of them:

• LogService, 3 or 5 nodes forming a Raft group (raft-paper), holding the write-ahead log.
• TN, one transaction node that decides whether a transaction may commit, serialises committed log records, and streams each table's WAL to the compute nodes subscribed to it. It is stateless, can be rebuilt from LogService "in just a few seconds", and can have a hot standby.
• CN, any number of compute nodes that run SQL. A big query can spread over several.

Table data lives in object storage (S3) as immutable objects of column-format row groups, arranged as an LSM tree ordered by primary key. Deletes are tombstone records in separate objects. Concurrency is MVCC "similar to that of the PostgreSQL database". A large transaction writes its data straight to object storage from the CN, bypassing the TN, and commits only the object metadata. Small writes collect in an append-only in-memory object at the TN, which each CN rebuilds from the WAL stream.

So a transactional database has been built from the parts analytical engines use: columnar immutable objects on S3 and an LSM tree, with commit made cheap by committing metadata instead of rows.

Git for data

Because objects never change, a snapshot is just the table's directory of object metadata. The version-control features follow from that:

• Clone copies the metadata directory, not the data. On TPC-H lineitem (100 GB scale, ~600M rows) a clone took 0.20 s and 314 KB; copying with INSERT … SELECT took 114.6 s and 34 GB.
• Diff scans only the objects added since the common base (Δ), with inserts and deletes as plus and minus signs.
• Merge is three-way. With a primary key, a row changed on both branches is a true conflict. A row that only moved (same values, new position after compaction) is treated as a false conflict, so the other branch's update is not lost. Resolution is SKIP or ACCEPT only, decided per row, not per cell. Any other resolution is manual SQL.
• Garbage collection keeps every object a named snapshot references.

Stated limits: no three-way diff exposed to users, secondary indexes are not cloned, and diff and merge stop working once either table's schema is altered.

Speed (maker-run, flagged). Built-in diff and merge of 1,000 to 1,000,000 changed rows took about 0.2–23 s with a primary key, against 316–549 s for the equivalent hand-written SQL. The paper calls this "100-500x". The baseline is the authors' own SQL on the same system, so the ratio shows how much the Δ-only scan saves. It is not a comparison with any other product. Without a primary key the built-in path is much slower (up to ~69 s) and does not rise steadily with change size.

The priority claim, checked

The paper's related-work section says: "As far as we know, no other database systems except MatrixOne offer native support of version control operations like diff and merge between forks of a database or table." This is not right. Dolt, a MySQL-compatible SQL database with fork, clone, branch, diff and merge on tables, has been public on GitHub since July 2019 (dolthub/dolt, Apache-2.0, ~24.5k★, checked 2026-09-23), and the paper does not mention it. In this corpus, seekdb (OceanBase, paged 2026-06-10) also offers copy-on-write FORK/MERGE. What MatrixOne adds is the mechanism above, with measurements: branching that falls out of immutable object storage.

Related

multiversion-concurrency-control · write-ahead-logging · raft-paper · online-transaction-processing · mysql · yugabytedb · citus · seekdb · operational-databases · synthesis