PUSHtap: Unified In-Memory HTAP with PIM

• PUSHtap is a PIM-based HTAP system that unifies OLTP and OLAP processing using a single in-memory data format to address the row vs column storage dilemma.
• It employs a two-dimensional CPU/PIM access model with ADE and IDE memory layouts to optimize throughput and minimize idle periods.
• The system integrates MVCC and lightweight controller extensions, achieving 3.4× OLAP and 4.4× OLTP throughput improvements compared to multi-instance designs.

Searching arXiv for the specified paper and closely related context. arXiv search query: (Zhao et al., 4 Aug 2025) PUSHtap is a PIM-based single-instance hybrid transaction/analytical processing (HTAP) system that introduces a unified in-memory data format for concurrent online transaction processing (OLTP) and online analytical processing (OLAP) within a single database instance. It is presented as the first PIM-based single-instance HTAP system with a unified in-memory data format, combining a unified data storage format, a two-dimensional CPU/PIM access model, multi-version concurrency control (MVCC), and extensions to a commercial DRAM-PIM architecture to support concurrent CPU/PIM use and new OLAP primitives. The system is designed to address the HTAP data-format dilemma, in which OLTP favors row-store layouts while OLAP favors column-store layouts, and reports 3.4× OLAP and 4.4× OLTP throughput improvement compared to a multi-instance PIM-based design (Zhao et al., 4 Aug 2025).

1. HTAP context and the data-format dilemma

HTAP is described as an emerging database paradigm that supports both OLTP and OLAP workloads. In this setting, computing-intensive OLTP operations, involving row-wise data manipulation, are suitable for row-store format, whereas memory-intensive OLAP operations, which are column-centric, benefit from column-store format. This opposition creates what PUSHtap terms a data-format dilemma: HTAP systems are prevented from concurrently achieving three design goals, namely performance isolation, data freshness, and workload-specific optimization.

PUSHtap addresses this problem by combining interleaved CPU access and localized PIM unit access. Its central idea is to use two orthogonal memory-access dimensions: rows are mapped onto the CPU-efficient device-interleave dimension, while columns are mapped onto the PIM-efficient in-device dimension. In the system description, this is framed as resolving the HTAP “impossible triangle” through a layout that can be interpreted as row-oriented from the CPU side and column-oriented from the PIM side.

The significance of this design lies in its single-instance organization. Because the raw layout is shared, neither engine requires format conversion. The paper characterizes the outcome as zero-copy freshness, meaning that OLTP-visible updates and OLAP-visible scans operate over a common physical representation rather than through asynchronous replication or re-materialization (Zhao et al., 4 Aug 2025).

2. Unified data storage format

The unified data storage format is organized around two dimensions: ADE and IDE. In the ADE dimension, defined as row-interleaving, the CPU sees consecutive 8 B chunks striped across $d$ devices for maximal burst bandwidth. In the IDE dimension, defined as bank-local, each PIM unit in its bank can read contiguous column fragments at $>3\times$ DRAM-bus bandwidth. This yields a two-dimensional memory organization in which CPU accesses are optimized across devices and PIM accesses are optimized within devices.

A central component is the Compact Aligned Format, which performs ADE×IDE alignment. With variable-width columns, naive padding to the widest column wastes both space and bandwidth. PUSHtap instead packs columns into “parts,” defined as groups of up to $d$ columns, using a bin-packing-style heuristic. Each part’s row-width is a multiple of $d\times 8$ B, enabling ADE alignment, while within each device each column datum is packed compactly, minimizing PIM-load waste.

The algorithm sketch proceeds as follows. First, the widest “key” column is picked and assigned to device 0 in part $k$. Second, other key columns greater than or equal to $th\times$(row-width) are greedily added to devices 1 onward. Third, remaining bytes are filled with “normal” columns, which may be split arbitrarily. Fourth, the process is repeated until all columns are placed. The hyperparameter $th\in[0,1]$ mediates a tradeoff between CPU and PIM bandwidth: $th\to 0$ gives best CPU (row) bandwidth and more parts, whereas $th\to 1$ gives best PIM (column) bandwidth and fewer parts.

PUSHtap further introduces Block-Circulant Placement to exploit IDE parallelism. If each column is compactly placed in one device, the corresponding PIM units become a hotspot. To avoid this, the table is divided into blocks of $B$ rows, and the column-to-device mapping is rotated across blocks. The description gives the pattern explicitly: in block 0, column $>3\times$0 maps to device $>3\times$1; in block 1, column $>3\times$2 maps to device $>3\times$3; and so on. This ensures that each column is evenly striped across all $>3\times$4 PIM units.

From the CPU viewpoint, the layout behaves as a row-store view: one row is read by issuing a single interleaved burst across $>3\times$5 devices, recovering all columns in one operation. From the PIM viewpoint, it behaves as a column-store view: PIM units scan one column in parallel, with each PIM pulling contiguous chunks of that column from its device. The coexistence of row-store and column-store views over a common layout is the defining storage abstraction of PUSHtap.

3. Two-dimensional CPU/PIM access model

PUSHtap extends a standard DRAM-PIM system, exemplified in the description by a UPMEM-like controller, with a Scheduler and Polling module. The access model interleaves “load” and “compute” phases at fine granularity so that PIM units lock banks only when loading data. During computation, they use on-chip WRAM and permit normal CPU access. This arrangement is intended to time-multiplex CPU and PIM use of the DRAM bus while minimizing idle periods.

For a single-column OLAP operation such as FILTER, the execution model consists of a Load phase and a Compute phase. In the Load phase, denoted by type=LS, the Scheduler hands over bank control to PIM, the PIM writes prior WRAM results back, and reads the next 32 kB column chunk using parameters including addr, length, and stride. The mode switch overhead is reported as approximately $>3\times$6/rank. In the Compute phase, denoted by type=Filter, the Scheduler returns bank control to the CPU, the PIM filters the WRAM buffer into a bitmap according to the predicate, and the CPU can run OLTP or proceed to the next column. By pipelining Load and Compute every 32 kB, CPU and PIM time-multiplex on the DRAM bus with minimal idle (Zhao et al., 4 Aug 2025).

The OLAP scan pseudocode uses $>3\times$7 kB chunks and alternates launchLS and launchFilter. For OLTP, CPU reads or writes one row by computing row_addr = base + row_id*row_stride, issuing memread(row_addr, row_stride) as a single interleaved burst, applying transaction logic, and then using clflush and mfence() to ensure freshness. The coupling of interleaved CPU row access and bank-local PIM column access is what the system describes as two-dimensional access.

This access model depends on explicit controller support. The launch request packet is specified as 1 B of “type” plus 63 B of parameters. The Poller auto-polls DPUs and signals completion via the standard read protocol, allowing the CPU to issue only one poll read. In effect, PUSHtap relocates synchronization and dispatch mechanisms into the memory controller so that concurrency between OLTP and OLAP becomes a low-level scheduling property rather than an application-level workaround.

4. MVCC and single-instance consistency management

PUSHtap implements MVCC entirely in shared DRAM banks using a two-region layout. The Data region stores immutable original rows in compact aligned and block-circulant form, while the Delta region stores appended new versions allocated in the same rotated block as the original. Each version row carries metadata in CPU memory: wr_ts as the create timestamp, rd_ts as the last read timestamp, and ptr as the link to the prior version.

Before each OLAP query, PUSHtap performs snapshotting. To avoid scanning all version chains on PIM units, the CPU builds and broadcasts a 2-bitmap snapshot, one bitmap per region. A bit $>3\times$8 is set to 1 if version-row $>3\times$9 is visible under the query timestamp $d$0. These bitmaps are stored in a reserved bank region, aligned ADE, and are consumed by PIM during scan to skip invisible rows. This design keeps visibility resolution on the CPU side while allowing PIM scans to remain sequential and bitmap-filtered.

The system also performs defragmentation every $d$1 k transactions. Old versions in the Data region become stale, while the Delta region contains the latest versions. PUSHtap moves the newest version back “in-place,” preserving the same device and same rotation, to overwrite the original using either CPU or PIM. The paper provides analytic cost models for CPU-only defragmentation and PIM-offloaded defragmentation, and states a threshold condition under which offloading to PIM is better. In practical terms, for $d$2 B, $d$3, and $d$4, PIM wins when $d$5 B (Zhao et al., 4 Aug 2025).

The measured overhead and benefit of this mechanism are explicit. Defragmentation takes less than 1.5% of OLTP time but prevents more than 2× OLAP slowdown from fragmentation. The paper therefore identifies a 10 k-transaction period as balancing cost versus freshness. Within the system’s architecture, MVCC is not an auxiliary layer added above the storage engine; it is integrated with the physical layout and PIM execution path.

5. PIM architecture extensions and instruction support

The architectural baseline is a commercial-style DRAM-PIM system similar to UPMEM. In the starting point described for PUSHtap, PIM mode versus CPU mode locks the entire rank, with tens of microseconds of overhead if used naively, and PIM units buffer only $d$6 kB in WRAM and therefore must stream. PUSHtap modifies this baseline by adding lightweight controller-side mechanisms rather than replacing the PIM execution substrate.

Two additions are emphasized. The Scheduler decodes memory-mapped launch and poll requests, hands over rank control only on LS and Defrag operations, and dispatches parameters to all DPUs through the on-chip network. The Poller auto-polls DPUs and signals completion via the standard read protocol. These changes reduce mode-switch cost to only hundreds of ns/rank during true DRAM bursts, while compute phases never lock banks. Under this scheme, the CPU can sustain OLTP latencies in the 10 $d$7 range.

PUSHtap also introduces new OLAP instruction forms, expressed as a type plus parameters. The listed operations are Load Stage (LS), Defragment, Filter, Group, Hash, Join, and Aggregate. These operations extend the PIM side from a simple scanning substrate to one able to participate directly in common OLAP primitives.

The reported hardware overhead is limited: Scheduler plus Poller occupy approximately $d$8 per 8-channel controller, which is less than 1% of approximately $d$9. This suggests that the system’s concurrency model is intended to be controller-centric and incremental with respect to existing DRAM-PIM designs rather than dependent on a wholesale redesign of the memory device.

6. Experimental configuration, results, and interpretation

The evaluation uses ramulator-pim together with zSim “OOO core,” DDR5-3200 DIMMs, 64 DPUs/rank at 500 MHz, $d\times 8$0 ranks with PIM plus $d\times 8$1 normal ranks, for a total of 64 PIM units. WRAM is 64 kB, of which only 32 kB is used. The CPU model is OOO with 64 B cache lines and private L1–L3 caches. The workloads are based on CH-benchmark, combining TPC-C and TPC-H. The OLTP side uses TPC-C Payment and NewOrder, accounting for 90% of the mix, on 6 tables with MVCC at 8 GB and 6 M rows scale. The OLAP side uses TPC-H Q1, Q6, and Q9 at scale = 20 GB (Zhao et al., 4 Aug 2025).

The principal results can be summarized as follows:

Aspect	Result	Context
OLTP layout cost	Column-store +28% slowdown vs. row-store; unified format +3.5% over ideal row-store	Layout sensitivity
OLAP freshness overhead	MI rebuilds +123% overhead at 1 M txns; snapshot+defrag +1.5%	Compared to ideal 100% bandwidth baseline
Long-run degradation	MI 13.3× slowdown at 8 M transactions; PUSHtap within 12.6% of ideal	Fragmentation and freshness
Throughput frontier	3.4× higher peak OLAP and 4.4× higher peak OLTP isolation than MI on DIMM-PIM	Isolation comparison

These results are framed against a multi-instance PIM-based design, abbreviated MI. The evaluation states that MI rebuilds incur 123% overhead at 1 M transactions relative to an ideal 100% bandwidth baseline, while PUSHtap’s snapshot plus defragmentation incurs only 1.5%. At 8 M transactions, MI suffers 13.3× slowdown, whereas PUSHtap remains within 12.6% of ideal. On the throughput frontier, PUSHtap achieves 3.4× higher peak OLAP and 4.4× higher peak OLTP isolation than MI on DIMM-PIM.

The HBM-PIM variant is presented more cautiously. PIM mode offload on HBM3 yields a marginal OLTP gain of 2.5% and mixed OLAP gains versus a custom accelerator, listed as ×1.6. The paper uses this to argue that general-purpose DIMM-PIM plus PUSHtap is cost-effective. A plausible implication is that the system’s advantages are strongest when the underlying PIM platform benefits from controller-mediated overlap and from a unified physical format, rather than when specialized accelerators already narrow the gap.

In aggregate, PUSHtap is presented as demonstrating that a single-instance in-memory HTAP system can approach row and column performance simultaneously by combining a unified ADE×IDE data format, two-phase CPU/PIM overlap, on-device MVCC support, and lightweight controller extensions. The conclusion additionally attributes full transactional correctness, sub-$d\times 8$2 OLTP latencies, and 3–4× better OLTP/OLAP isolation than prior multi-instance PIM designs to this integrated design (Zhao et al., 4 Aug 2025).