An in-memory database turns DRAM capacity into a business constraint. A server with too few DIMM slots must either buy higher-capacity modules at a premium or split the database across more machines. CXL promises a third option: detach some capacity from the CPU socket and allocate it when an instance needs it. The promise becomes harder once a switch sits in the path and two hosts share the box.
This EDBT Industrial & Applications paper matters because it uses a commercial-grade CXL memory box rather than an emulator.[1] SAP and Samsung researchers connect an XConn switch and Samsung CMM-D memory devices to real Emerald Rapids servers, modify a HANA prototype and run TPC-C, TPC-DS, restart and temporary-table experiments. The paper does not claim that pooled memory is equivalent to local DRAM. It identifies which HANA structures can tolerate the pool and which cannot.
What “dynamic” means in this prototype
The small topology has two hosts connected to an XConn B2 CXL switch. The switch supports up to 256 PCIe 5.0 lanes. Two downstream Samsung CMM-D devices each contain 128 GB of DDR5-5200, a memory controller, a CXL-to-DDR5 ASIC and a PCIe 5.0 x8 interface. Each host reaches the switch through an x16 upstream port and sees a 256 GB host-managed device memory (HDM) range.
The fabric manager controls the mapping from each upstream HDM range to downstream devices. In principle it could reprogram that mapping. The evaluation does not use live switch remapping because of stability concerns. Instead, Linux onlines and offlines already mapped memory regions and exposes them as NUMA nodes or fsdax devices. That distinction is important. The paper demonstrates runtime capacity activation without a reboot, but not arbitrary byte-range reassignment by the switch while HANA is actively using the region.
The two hosts receive disjoint regions. They draw capacity from one physical box, yet they do not concurrently share the same table or temporary buffer. Cross-host coherent sharing is future work. Here, pooling means flexible partitioning of capacity among hosts, not a common coherent address range used by two HANA instances.
Distinct memory consumers inside HANA
The main column store is large, read-dominant and often scanned sequentially. HANA’s operational heap holds intermediate execution structures, hash tables and short-lived objects whose accesses can be random and write-intensive. SQL scripts may create temporary tables that grow with the number of concurrent users. Restart adds another dimension: main storage can persist in a memory region and avoid reloading from disk.
Treating these structures as one “database memory” category would hide the result. Sequential scans can prefetch long CXL accesses and are often limited by aggregate bandwidth. Random heaps expose every additional nanosecond and cannot build enough memory-level parallelism. Temporary tables may be large but lightly accessed, making capacity more important than raw latency.
The HANA prototype adds NUMA-aware far-memory allocation to its execution engine and lets selected temporary tables target a specific NUMA node. The authors explicitly note that these prototype features are not a commitment about near-term commercial HANA availability.
Test 1: table data and operational heap
The first machine uses one 48-core Emerald Rapids processor with hyper-threading and 1,024 GB of local DDR5-4800 across eight channels. The CXL memory box contains one switch and two memory devices. Both direct-attached CXL and the switched pool are placed behind the remote socket path so the experiment can compare substrates under a controlled NUMA penalty.
TPC-C with 100 warehouses produces little CXL traffic and has substantial synchronization overhead. Moving the main table storage or selected allocations therefore has negligible effect. This is not proof that OLTP prefers far memory. It means memory latency is not the limiting term in this configuration.
TPC-DS at scale factor 100 is more revealing. Moving main storage to the pool causes visible loss as parallel streams increase. Sequential access lets prefetching hide much of the latency, so bandwidth becomes the principal constraint. The authors stripe two fsdax devices with Linux device mapper to double available CXL bandwidth. With that configuration, degradation versus the all-local baseline falls to a single-digit percentage. A small difference remains between local- and remote-socket pool placement because dictionary accesses contain a random component.
The operational HEX heap is the clear rejection case. Prior and current experiments find more than 50% degradation when this random-access heap is placed in CXL memory, even with a direct-attached device that is faster than the switched pool.[2] The paper therefore excludes it as a viable pooling target. Capacity elasticity does not compensate for a data structure that converts latency directly into stalled execution.
Test 2: fast restart
HANA normally reloads main table data from persistent volumes during restart. Its fast-restart mechanism can preserve main-storage fragments in a persistent memory region and reattach them after the service returns. The experiment places main storage in the CXL pool, performs a controlled shutdown and compares three normalized cases: no preload, full preload without fast restart and full preload with fast restart.
Keeping data in the pool removes most of the preload phase. However, the figure reports normalized time rather than absolute seconds, and the experiment assumes the delta store is fully merged so redo time is negligible. The correct conclusion is that a persistent CXL region can eliminate bulk reload for the evaluated state. It does not establish recovery time under power loss, fabric-manager failover, dirty delta logs or a failed memory box.
Test 3: temporary tables on two hosts
The two-host experiment uses dual-socket Emerald Rapids systems. Each socket in server A contains 1 TB of local DRAM, whereas server B provides 512 GB on each socket. Both online an additional 128 GB from the same pool. The workload consists of SQL scripts derived from the five TPC-DS queries with the largest temporary-table footprints.
Performance is effectively unchanged when temporary tables move from local DRAM to remote DRAM or the CXL pool. These scripts access the tables mostly sequentially and generate little CXL traffic, so queues remain below saturation. The result is operationally useful: a large but lightly accessed intermediate can move out of scarce local memory to prevent out-of-memory failure.
The authors then run workloads concurrently on both hosts. Interference remains negligible at the measured traffic level. This is a low-load isolation observation, not proof of quality of service. The same paper warns that bandwidth-heavy workloads can contend at the device and switch, and its plots do not explore adversarial read-write combinations at line rate.
The three deployment rules
First, classify data by access shape, not by database object name. Table columns, dictionaries, temporary tables and execution heaps can have different read-write ratios and locality. A placement controller should use measured bandwidth, cache-miss behavior and lifetime rather than a static rule that sends all “cold” data away.[3]
Second, capacity activation and performance isolation are separate features. Linux can online 128 GB without a restart, but that memory is only useful if another host cannot saturate the shared downstream device. A deployable memory box needs per-host bandwidth telemetry, admission control and a method to move or throttle allocations before tail latency violates the database SLO.
Third, persistence expands the failure contract. Retaining main storage across a HANA restart is valuable, but the system must define what survives a switch reset, cable failure, firmware update and memory-device replacement. The pool cannot become a single recovery dependency without replicated metadata and a tested fallback to storage.
What to verify before buying
An acceptance test should first reproduce the six table-placement configurations with the operator’s own query mix. Report throughput together with CXL read/write bandwidth, CPU stall counters and p99 query latency. Doubling links should be treated as a costed configuration, not a free optimization.
Next, run two tenants with deliberately conflicting patterns: one sequential bandwidth stream and one random latency-sensitive workload. Increase traffic until interference appears, then verify whether the fabric manager or database can protect the random workload. Finally, repeatedly online and offline capacity while queries allocate temporary state, inject a link reset and recover the database from the persistent pool.
The paper’s strongest contribution is not that CXL makes HANA faster. It shows that a real switch and memory box can make capacity elastic without harming carefully selected structures. The boundary is equally valuable: random operational state must remain close to the CPU, and shared bandwidth must be managed as a first-class database resource.
Source and attribution
This article is an editorial analysis prepared by Silicon & Systems. The paper’s arguments and measurements are restated in our own words. We do not reproduce its text, figures or tables; both figures were created for this article. The original is available from OpenProceedings EDBT 2026, DOI 10.48786/edbt.2026.58, under CC BY-NC-ND 4.0. Copyright is held by the owners/authors, (c) 2026.