TPC-C

TPC-C is the canonical online transaction processing (OLTP) benchmark from the Transaction Processing Performance Council. Published in 1992 and still widely cited, it models the order-entry activity of a wholesale supplier with multiple distributed warehouses. It remains the reference point for measuring raw transactional throughput on relational databases, and its design philosophy — a fixed transaction mix, mandatory ACID properties, and audited reporting — set the template that nearly every later database benchmark followed.

What It Measures

TPC-C reports throughput as tpmC — new-order transactions completed per minute — and a derived price/performance figure in cost per tpmC. The workload mixes five transaction types: New-Order, Payment, Order-Status, Delivery, and Stock-Level. Only New-Order transactions count toward tpmC, but all five must run concurrently in fixed proportions. The benchmark stresses concurrency control, locking, write-ahead logging, and disk I/O under heavy contention.

Methodology

The schema has nine tables (Warehouse, District, Customer, Order, Order-Line, Item, Stock, History, New-Order). Data volume scales with the number of warehouses: each warehouse adds a fixed set of rows and a population of terminals. A valid run must satisfy strict ACID and isolation requirements, keyed-entry and think-time delays per emulated user, and a response-time constraint (90th percentile under a threshold). The system must also demonstrate durability by surviving a power-loss test. Results are audited before publication. Because the data set grows with warehouses, vendors often run thousands of warehouses to reach high tpmC.

How to Interpret Results

Compare tpmC only between systems of similar scale and configuration, and always read it alongside price/performance and the total system cost. A high tpmC achieved with an enormous, expensive cluster is not comparable to a modest single-node result. Check the full disclosure report for the warehouse count, isolation level, and hardware. Many published numbers are years old, so for current decisions use a TPC-C-style tool like HammerDB or BenchBase to run the workload on your own hardware rather than relying on the official leaderboard.

Limitations

TPC-C reflects a 1990s order-entry pattern with short, uniform transactions and high contention on a few hot rows. It does not represent analytical queries, JSON or document workloads, or modern microservice access patterns. The mandated think times and keying delays make it sensitive to client emulation, and full audited runs are expensive, so most practitioners use unaudited derivative tools. Treat it as a contention-and-durability stress test, not a complete picture of database performance. Despite its age, it endures because the problems it surfaces — lock contention on hot rows, log-write bottlenecks, and durability under failure — remain central to transactional systems today.