Skip to content

CONCEPT Cited by 1 source

Mixed-workload contention

Mixed-workload contention is the pathology that arises when a single database tries to serve both OLTP and OLAP shapes from the same physical resources (CPU, memory, I/O bandwidth). The two workload shapes have structurally incompatible resource profiles: OLTP needs low-latency small operations with tight tail-latency SLOs; OLAP needs long-running scans and aggregations that saturate CPU and memory. Running them on shared resources means each penalises the other.

This is the structural reason HTAP is hard to deliver at scale, and the reason PlanetScale explicitly disclaims HTAP in favour of pure-OLTP + warehouse offload (Source: sources/2026-04-21-planetscale-what-is-htap).

How the contention manifests

Two distinct failure shapes enumerated in the HTAP taxonomy (Source: sources/2026-04-21-planetscale-what-is-htap):

  • Challenge #1 — mixed workload complexity. "HTAP databases aim to accommodate both transactional and analytical tasks within a single system. However, this leads to a complex environment where the database must juggle the demands of high-speed transaction processing and resource-intensive analytical queries. This inherent conflict in requirements can result in performance compromises."

  • Challenge #5 — resource contention. "Contention arises when transactional and analytical workloads vie for the same resources, such as CPU, memory, and I/O bandwidth. This contention can lead to resource bottlenecks, unpredictable performance fluctuations, and overall system instability."

  • Challenge #2 — performance trade-offs. "Optimizing for one workload often comes at the expense of the other. For instance, in pursuit of quick transaction processing, analytical queries might experience slowdowns due to the shared resources. Conversely, if resources are allocated to enhance analytical performance, transactional operations could suffer, leading to increased latencies and reduced throughput."

Why it's structural, not tunable

The three contention modes compound:

  1. CPU contention. OLAP scans consume whole cores for seconds to minutes; OLTP point queries need microsecond-scale CPU time slices. A single long OLAP scan can block OLTP scheduling even under fair CPU policies if the OLAP query holds a core through its window.
  2. Memory pressure. OLAP scans evict OLTP working sets from the buffer pool; OLTP hot rows then read from disk, inflating transactional latency.
  3. I/O bandwidth. Analytical table scans saturate sequential I/O bandwidth; OLTP random reads compete for the same physical disk queues and see increased queueing delays.

Tuning knobs (query priority, resource pools, workload classes) mitigate but don't eliminate the contention because the underlying hardware resources are finite and shared.

Canonical mitigation: physical isolation

The PlanetScale-recommended mitigation is physical resource isolation — don't share physical resources across workload classes. Verbatim:

Physical resource isolation is an effective way to guarantee the performance of transactional queries. Analytical queries often consume high levels of resources such as CPU, memory, and I/O bandwidth. If these queries run together with transactional queries, the latter can be seriously delayed.

Operationally this becomes:

Mixed-workload contention is a special case of concepts/noisy-neighbor where the "noisy" tenant and the "quiet" tenant are the same tenant's two workload shapes. The fix (physical isolation, quota/priority classes, workload-aware scheduling) is the same.

Seen in

  • sources/2026-04-21-planetscale-what-is-htap — canonical wiki introduction. Savannah Longoria enumerates mixed-workload contention as the core structural reason HTAP is hard at scale and frames physical-resource-isolation + specialised-warehouse- offload as the PlanetScale-recommended alternative.
Last updated · 470 distilled / 1,213 read