CONCEPT Cited by 1 source

HTAP (Hybrid Transactional / Analytical Processing)¶

HTAP is a database category promising to serve both OLTP and OLAP workloads from a single system — collapsing the traditional two-system split (transactional database + separate analytical warehouse connected by ETL/ELT) into one engine. The term was popularised in the 2010s by vendors positioning HTAP as "a promising new computing paradigm that will solve performance, cost, and complexity challenges that arise from managing two separate workloads" (Source: sources/2026-04-21-planetscale-what-is-htap).

In practice, HTAP systems face eight structural challenges that make them hard to scale on workloads where OLTP and OLAP shapes are both heavy — which is why pure-OLTP vendors like PlanetScale explicitly disclaim HTAP and instead recommend offloading OLAP to a specialised warehouse.

Architecture classes¶

Three broad architectural approaches to HTAP (Source: sources/2026-04-21-planetscale-what-is-htap):

Class	Data layout	Pros	Cons
Shared-everything	All data in a single shared storage system	Simplest to implement; data consistency is natural	Scale-limited
Shared-nothing	Each node stores its own data	Horizontally scalable	Harder to implement + manage
Hybrid	Transactional data in shared-everything + analytical data in shared-nothing	Combines strengths	Consistency hard under concurrent tx/analytical ops; scale-limited

Implementation styles¶

Four observed HTAP implementation styles (Source: sources/2026-04-21-planetscale-what-is-htap):

In-memory HTAP. Each node stores its data in memory. Horizontally scalable, but consistency-hard and memory-expensive.
Columnar HTAP. Uses a columnar storage format optimized for analytical queries. Good analytical performance, slower for transactional queries (row-reads are hostile on column-oriented storage).
Separation of storage and compute. Decouples storage from processing — see concepts/compute-storage-separation.
Hybrid on-disk-plus-in-memory. Transactional data on disk, analytical data in memory.

The eight structural challenges¶

From PlanetScale's What is HTAP? post, an enumeration of the structural problems that hinder HTAP systems at scale:

Mixed workload complexity. The database juggles high-speed transactions and resource-intensive analytical queries. "This inherent conflict in requirements can result in performance compromises." See concepts/mixed-workload-contention.
Performance trade-offs. Optimising for one workload penalises the other via shared resources. Quick transaction processing slows analytical queries; allocating resources to analytics increases transactional latency.
Data model mismatch. OLTP updates individual records and maintains integrity + consistency; OLAP does complex aggregations and scans. Fitting both into the same data model "can lead to suboptimal design compromises that hinder efficient processing for either workload." See concepts/data-model-mismatch.
Scalability challenges. Horizontal scale of both transactional and analytical components simultaneously is hard: "Balancing the expansion needs of both transactional and analytical components becomes increasingly complex as the system grows."
Resource contention. CPU, memory, and I/O bandwidth contention between workload classes leads to "resource bottlenecks, unpredictable performance fluctuations, and overall system instability."
Maintenance + administration complexity. HTAP databases "demand more intricate administration and maintenance compared to standalone OLTP or OLAP systems" — tuning and configuring for two workload shapes at once is operationally heavier.
Limitation in analytical processing. Specialised analytical warehouses "can employ more sophisticated optimization techniques for complex analytical operations, offering superior performance and richer insights." HTAP analytical capability is bounded above by dedicated warehouses.
Evolution of data processing architectures. Modern distributed / microservices / serverless architectures are "designed to optimize specific types of workloads," making it "challenging to fit a hybrid database into the larger application ecosystem."

PlanetScale's explicit non-HTAP position¶

PlanetScale publicly disclaims HTAP. Verbatim from sources/2026-04-21-planetscale-what-is-htap:

PlanetScale does not claim to be an HTAP database, nor are we an OLAP database built for pure analytical workloads. Instead, PlanetScale offers the only managed Vitess solution and we are optimized for OLTP workloads.

The recommended alternative: physical resource isolation — don't share physical resources across workload archetypes; for OLAP, offload to a specialised warehouse via ETL/ELT using integration engines like Airbyte, Fivetran, or Stitch. Complements the PlanetScale Support Notes framing of the per-session set workload='olap'; toggle as a deliberate-friction in-envelope escape hatch, and the building-data-pipelines post's framing of CDC as the architectural motivation for OLTP→OLAP offload.

When HTAP might still work¶

The post doesn't enumerate positive use-cases, but by implication:

Workload where OLTP and OLAP are both light. When neither workload saturates shared resources, contention is sub-critical.
Workload where OLAP latency SLOs are relaxed. If analytical queries can tolerate transactional-workload-induced slowdown, the shared-resource penalty is acceptable.
Single-node deployments. If horizontal scale isn't needed, challenges (4) scalability and partly (5) resource contention are bounded by single-node capacity; simpler shared-everything HTAP becomes viable.

Seen in¶

sources/2026-04-21-planetscale-what-is-htap — canonical wiki introduction to the HTAP category as a distinct workload-archetype framing alongside OLTP and OLAP. Savannah Longoria (PlanetScale, 2023-12-01) defines HTAP, enumerates the three architecture classes + four implementation styles + eight structural challenges, and canonicalises PlanetScale's explicit non-HTAP position statement "PlanetScale does not claim to be an HTAP database" + the alternative recommendation of physical resource isolation + ETL-offload via Airbyte / Fivetran / Stitch to a specialised OLAP warehouse. Pedagogy- altitude; no production numbers; no specific HTAP vendor engagement; but durable taxonomic framing beneath the wiki's prior OLTP-vs-OLAP coverage.