CONCEPT Cited by 1 source

Physical resource isolation¶

Physical resource isolation means running workloads with distinct resource-demand profiles on separate physical machines (or at least separate VMs / containers with hard resource limits) rather than sharing CPU, memory, and I/O bandwidth across them. It's the canonical fix for mixed-workload contention and the reason HTAP systems struggle at scale.

Canonical verbatim framing¶

From sources/2026-04-21-planetscale-what-is-htap:

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.

The load-bearing word is physical: not query-priority queues, not resource pools inside a single database instance, not cgroup soft limits — separate hardware (or hard-walled virtualised hardware) so that a resource-hungry analytical query simply cannot starve a transactional one.

Why soft isolation isn't enough¶

Shared-database workload classes (per-query priority, concepts/query-priority-classification, resource pools) reduce but don't eliminate contention:

Shared buffer pool — an OLAP scan still evicts OLTP hot rows even under priority scheduling; the buffer pool is the same physical memory.
Shared I/O queue — priority can weight queue ordering but cannot create I/O bandwidth that isn't there.
Shared CPU — a core executing an OLAP scan for 500ms cannot simultaneously execute an OLTP point query in that window.
Shared lock manager — long-running OLAP queries can hold metadata / MVCC-horizon locks that block OLTP DDL/vacuum.

Physical isolation routes around all of these by keeping the resources themselves separate.

Operational instantiations¶

Separate databases per workload. OLTP cluster + OLAP warehouse; connected by ETL/ELT or CDC. See patterns/workload-segregated-clusters.
Separate replica topologies. One replica serves OLTP reads; a dedicated read replica pool serves long-running analytical queries with looser SLOs. In Vitess-land this maps to tablet types (REPLICA vs RDONLY / BATCH).
Per-session OLAP escape hatch with deliberate friction. PlanetScale's set workload='olap'; per-session lift of [[concepts/planetscale-hard-transaction-query-timeouts|20s/900s hard timeouts]] is framed as a last-resort in-envelope tool, explicitly preferring physical isolation via ETL offload. (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field)
Dedicated analytics warehouse. The canonical OLAP architecture: Snowflake / BigQuery / Redshift / Databricks fed by Airbyte, Fivetran, or Stitch. Specialised warehouse provides OLAP-optimised storage + execution without OLTP contention.

Tenant isolation as a generalisation¶

Physical resource isolation extends beyond OLTP/OLAP splits to any concepts/tenant-isolation boundary where shared resources enable noisy-neighbor failures. The same principle underlies:

Per-tenant dedicated capacity for high-paying customers;
Separate control-plane / data-plane fleets (concepts/control-plane-data-plane-separation);
Per-workload-class cgroups / namespaces / VMs in shared-compute platforms.

Trade-offs¶

Cost. Two physical systems cost more than one — doubled hardware, doubled operational surface, doubled on-call rotation.
Data freshness. OLAP is fed by pipelines (ETL/ELT/CDC) that introduce latency — analytical queries see data that is seconds to minutes to hours old depending on pipeline design.
Consistency across systems. OLTP is source-of-truth; warehouse data is derived. Cross-system queries (e.g. JOIN an OLTP user table with a warehouse aggregate) require careful consistency semantics.
Skill-set + tooling duplication. Two different query engines, two different schema-evolution tools, two different monitoring stacks.

These costs are what make HTAP marketing appealing — a single system avoids them. The argument against HTAP (Source: sources/2026-04-21-planetscale-what-is-htap) is that the duplication cost is less painful than the contention cost.

Seen in¶

sources/2026-04-21-planetscale-what-is-htap — canonical wiki introduction. Savannah Longoria (PlanetScale, 2023-12-01) canonicalises physical-resource-isolation as the PlanetScale-recommended alternative to HTAP: "Physical resource isolation is an effective way to guarantee the performance of transactional queries." The post pairs this with the concrete offload recommendation — Airbyte / Fivetran / Stitch to a specialised OLAP warehouse — as the operational instantiation.