3810.36 Points! Inside GBase 8c's HyBench Record: How One Copy of Data Serves Both Transactions and Analytics

What does a HyBench score of 3810.36 mean? The test ran at 1000X scale, with a transaction stream table of 6 billion rows. The system sustained over 90,000 OLTP transactions per second while keeping analytical data freshness at zero. The significance of this result lies not just in being "fast," but in being real-time: analytical queries do not read yesterday's snapshot — they read the row that was just committed. This article breaks down how GBase 8c's dual row-column storage mechanism resolves the physical conflict between transactions and analytics at the underlying level.

What Makes This Score So Hard to Achieve?

A leaderboard score only shows the result. To understand its significance, you first need to see how difficult the exam was.

In the Database Benchmark Test Report (No. ZT022607875) issued by the China Software Testing Center (CSTC) in July 2026, the HyBench benchmark ran at 1000X data scale — with the transaction stream table alone reaching 6 billion rows.

What makes it harder is the workload model. HyBench is not a single-discipline test; it drives both transactional and analytical workloads against one system simultaneously:

• Extreme concurrency: over 90,000 OLTP TPS (pure transaction throughput)

• Heavy computation: aggregation queries spanning 6 billion rows

• The critical factor: data freshness of zero

"Freshness" measures the time gap between the data an analytical query sees and the data just committed by a transaction. Zero means analytical queries are not reading from the previous snapshot batch at all — they see the row that was just committed.

If this metric were not zero, then no matter how high the throughput, it would essentially be "HTAP with a real-time discount" — differing from a traditional dual-system-plus-ETL setup only in synchronization frequency. If you want true real-time behavior, you must make changes at the root of physical storage.

The Core Conflict: The Physical Incompatibility of Row-Store and Column-Store

Why has HTAP been so difficult for the past decade and more? Because transactions and analytics have nearly opposite storage requirements:

Row-store (for transactions): Data is stored contiguously by row. A point lookup touches only one or two data pages, and writes are extremely fast. But a full-table aggregation must read every column of every row — the vast majority of that data is read for nothing.

Column-store (for analytics): Data is stored and compressed by column. Aggregation reads only the columns involved in the computation, minimizing scan volume. But single-row updates are extremely painful — the system must locate the row inside a large column block, and may even rewrite an entire compressed block.

The traditional solution is physical isolation (two databases plus CDC/ETL movement). Isolation solves the performance conflict, but introduces data latency and pipeline inconsistency.

GBase 8c's breakthrough approach maintains two physical organizations — row-store and column-store — on the same table simultaneously. Note: these are two physical organizations, not two data replicas. Making these two opposite physical structures work together relies on a set of precision-engineered mechanisms at the underlying level.

Mechanism Breakdown: How Two Engines Run on One Copy of Data

To make real-time behavior possible, GBase 8c performs fine-grained modular partitioning of data at the underlying level.

1. How Data Is Stored: From Row Blocks to Compression Units (CUs)

In GBase 8c, row-store and column-store are not interleaved in a disorganized way. The system horizontally partitions a row-store table into row blocks, each spanning 1,024 physical pages (approximately 8 MB).

The system then creates a row group for each row block and decomposes the data within that row block by column, generating individual compression units (CUs) — one CU per column in the row group. Each CU carries metadata such as transaction timestamps. At query time, the system inspects CU metadata to decide whether a CU needs to be read, substantially reducing unnecessary I/O.

2. Handling Real-Time Updates: The Delta Table as a Buffer

The weakness of column-store is that it cannot withstand high-frequency single-row writes. If every transaction triggered a rewrite of column-store CUs, the system would grind to a halt.

GBase 8c's solution introduces a Delta table — essentially a buffer table with a row-store structure. New transactions first land in the Delta table as a record. Once a certain volume accumulates, a background process asynchronously merges them into the column-store CUs. The Delta table uses page-level recording: each physical page records only a single entry if it has any modification, rather than one entry per row. Assuming an average of 100 rows per page, 1 million rows require only about 10,000 records in the Delta table. This dramatically compresses Delta table size, with negligible performance impact.

3. How Queries Read: Merged Reads and Automatic Path Selection

When a business analytical query is issued, the query optimizer automatically determines whether to use row-store or column-store. If column-store is chosen, the system scans the CUs and reads the incremental data from the Delta table, merging both into the output. This is the fundamental reason freshness is zero: newly committed writes are immediately visible, with no refresh cycle.

The Deep End: Solving HTAP's "Cognitive Bias"

The mechanism sounds perfect, but in real high-concurrency engineering there is an extremely subtle pitfall: information inconsistency between the CN (coordinator node) and the DN (data node).

Put simply, execution plans are generated by the CN (the brain), while data changes are recorded on the DN (the hands and feet). The CN has no awareness of how much incremental data has accumulated in the Delta table on the DN side. This leads the CN to be "blindly optimistic": it estimates cost based solely on the static data inside the CUs, assuming queries will be fast, when in reality the underlying data may already be highly fragmented. Left unchecked, column-store performance would steadily degrade.

To resolve this "cognitive bias," GBase 8c implements two safeguards:

Safeguard 1: Threshold-triggered CU rebuild. When physical page changes exceed 200 pages, or row inserts and deletes exceed 30,000 rows, the system forcibly queues the task and, during idle time, rescans from row-store to build entirely new CUs and write them to disk.

Safeguard 2: Row-store fallback. If a scan finds that a CU is an old version, the system retrieves complete data directly from row-store. This is precisely the value of dual row-column storage: during column-store rebuilds, even if queries temporarily fall back to the row-store path and run somewhat slower, data is never missed and results are never wrong.

Details: The Engineering Decisions That Kept 6 Billion Rows From Becoming a Bottleneck

Beyond the core mechanisms, this result also depended on a few key decisions in the table DDL:

• Well-chosen distribution keys: The transaction stream table is hash-distributed by source account (sourceID), and the account table by account ID. When aggregating by account dimension, the data is already co-located on the same node, eliminating the network overhead of cross-node redistribution.

• Range partitioning: The transaction stream table is partitioned by timestamp on a monthly basis. When a query needs only a 60-day window, partition pruning skips all other partitions, instantly narrowing the scan from 6 billion rows.

• Fill factor (fillfactor = 80): For frequently updated tables, 20% of each data page is reserved as free space. This keeps new versions of updated rows on the same page as much as possible, reducing page splits. A single SQL statement shows no difference, but across a 48-minute mixed stress test, this prevents the performance cliff caused by table bloat.

3810.36 is this architecture's report card, but the "0" in freshness is the core of the underlying engineering strength. HTAP has never been only about peak performance — it is about the real-time vitality of data. With this precisely interlocking set of underlying mechanisms, GBase 8c breaks down the physical barriers between transactions and analytics, turning "fast and accurate at the same time" from a vision into an industry standard.