TPC-E

TPC-E is an online transaction processing benchmark from the Transaction Processing Performance Council, introduced in 2007 to model a more realistic and complex workload than TPC-C. It simulates the activity of a brokerage firm whose customers trade securities, query account status, and run market research. It is designed to be harder to game and more representative of contemporary enterprise OLTP.

What It Measures

The primary metric is tpsE — trade-result transactions per second — together with price/performance. TPC-E uses 12 transaction types, a mix that is more read-heavy than TPC-C and includes complex queries against customer, account, and market data. The benchmark stresses concurrency, mixed read/write workloads, referential integrity, and disk I/O patterns closer to real applications.

Methodology

The schema has 33 tables spanning customer, broker, and market domains, with referential-integrity constraints and check constraints that databases must enforce. Initial data is generated from pseudo-real distributions — for example, names and addresses drawn from census-like sources — making the data less uniform and harder to compress or pre-aggregate than TPC-C's. Scaling is driven by the number of customers. A compliant run must meet response-time limits, sustain a steady state, and pass an ACID and durability test. Like other TPC benchmarks, official results are independently audited and published with a full disclosure report.

How to Interpret Results

Compare tpsE only across similar configurations, and always read price/performance and total system cost alongside it. tpsE values are numerically much smaller than tpmC and the two are not interchangeable. Inspect the disclosure report for customer count, isolation level, and storage configuration. TPC-E adoption is narrower than TPC-C, with fewer published results, so it is most useful when comparing systems that have official TPC-E numbers or when you reproduce a TPC-E-style workload on your own hardware.

Limitations

TPC-E is operationally complex and expensive to run in full, which limits the number of published results and thus head-to-head comparisons. It models a specific brokerage domain and read-heavy mix that may not match your application. It is also a relational benchmark and does not address NoSQL, document, or analytical workloads. Use it as a more realistic OLTP stress test than TPC-C, while recognizing its limited ecosystem of comparable results. Where it is reported, it offers a more faithful view of contemporary enterprise transaction processing than the older TPC-C, particularly for read-heavy, query-rich applications. Teams that cannot run the full audited kit often reproduce its central trade-result transaction and a few read queries to approximate its more realistic profile.