Dolt is a version-controlled database that works as a drop-in MySQL replacement. In addition to correctness parity with MySQL, we are also determined to reach performance parity with MySQL. For years now, we’ve been improving Dolt performance on both Sysbench and TPC-C benchmarks. Towards the end of 2025, Dolt reached parity with MySQL on Sysbench when averaging reads and writes. Shortly after, we managed to reach MySQL parity on both read and writes. Now, we surpass MySQL on Sysbench reads and writes with a 0.95 reads mean multiplier and 0.87 write mean multiplier.

While we are proud of our accomplishments on Sysbench, TPC-C Benchmarks are arguably more important to the average user experience. This blog will go into detail about the TPC-C benchmarks and the kinds of queries run against the database.

What is TPC-C#

TPC-C stands for Transaction Processing Performance Council Benchmark C. It is the industry standard benchmark used for OLTP databases. TPC-C simulates real-world usage of a database by modeling transactions for a wholesale supplier. Dolt actually uses a slightly modified version of the official TPC-C benchmarks from Percona Labs.

Settings#

We run TPC-C with these settings:

./tpcc.lua \
  --db-driver="mysql" \
  --mysql-db="sbtest" \
  --mysql-host="127.0.0.1" \
  --mysql-port="$PORT" \
  --mysql-user="$USER" \
  --mysql-password="$PASS" \
  --time=800 \
  --report_interval=10 \
  --threads=1 \
  --tables=1 \
  --scale=1 \
  --trx_level="RR" run

The benchmarks are run with a single thread for 800 seconds with autocommit and foreign_key_checks disabled. trx_level="RR" is REPEATABLE_READ (the MySQL/Innodb default), which means that SELECT results are isolated within a transaction. Uncommitted writes to a table from another transaction will not be visible to this transaction. We compare the 95th percentile latency and number of transactions per second (tps) against MySQL.

Tables#

Here is a brief summary of the tables created.

• warehouse with 1 row
• district with 10 rows
• customer with 30000 rows
• orders with 30000 rows
• new_orders with 9000 rows
• order_line with 299293 rows
• item with 100000 rows
• stock with 100000 rows
• history with 30000 rows

Many of these tables have primary keys, secondary keys, and foreign keys (even though foreign_key_checks are disabled).

Transactions#

TPC-C randomly selects between 5 different transaction types with varying odds. Each transaction starts with a BEGIN and ends with COMMIT. Without spelling out every query run within a transaction, here is a high-level overview of each transaction.

trx_type	run_percent
new_order	43.48%
payment	43.48%
order_status	4.35%
delivery	4.35%
payment	4.35%
TOTAL	≈100.00%

1. new_order#

Description: This transaction simulates a customer order of 5 - 15 quantity of an item. The new order is logged in the orders, new_orders, and order_line tables, and the item and stock tables are updated accordingly.

Percent Run: 43.49% (10/23)

# of SQL Statements: 25 - 65

Reads Tables: customer, district, item, stock, warehouse

Writes Tables: district, orders, order_line, new_orders, stock

2. payment#

Description: This transaction simulates a customer making a purchase. It reads the customer’s payment details (name, address, etc.) from the customer table, update their account balance, and logs the transaction in the history table.

Percent Run: 43.48% (10/23)

# of SQL Statements: 6 - 10

Reads Tables: customer, district, warehouse

Writes Tables: customer, district, history, warehouse

3. order_status#

Description: This transaction simulates a customer inquiring about their order details. It performs a series of SELECT queries into the customer, orders and order_line tables.

Percent Run: 4.34% (1/23)

# of SQL Statements: 3 - 4

Reads Tables: customer, orders, order_line

Writes Tables:

4. delivery#

Description: This transaction simulates a customer’s order getting delivered. An order is removed from the new_orders table and the appropriate entries are updated in orders, order_line and customer.

Percent Run: 4.34% (1/23)

# of SQL Statements: 1 - 6

Reads Tables: orders, order_line, new_orders

Writes Tables: customer, orders, order_line, new_orders

5. stocklevel#

Description: This transaction simulates a query over existing inventory. It is a few SELECT queries that aggregate over the order_line and stock tables that count the quantity of certain items.

Percent Run: 4.34% (1/23)

# of SQL Statements: 3+

Reads Tables: district, orders, stock, order_line

Writes Tables:

You can explore the TPC-C database in more detail here: https://www.dolthub.com/repositories/jcor/sbtest

Conclusion#

We have been focused on Dolt performance on TPC-C, which aims to simulate a real user experience with an OLTP database. Over the last few months we have made substantial improvements to TPC-C. Stay tuned for a future blog describing how we’ve broken the 2x MySQL multiplier on TPC-C. Have any performance issues? Cut a bug on our GitHub issues page. Want to talk to anyone on our team? Join our Discord.