JSONB, JIT, and HeatWave Redefine OLTP Boundaries by 2026

Between 2018 and 2026, two forces quietly rewired the way relational engines execute modern workloads: a burst of core execution advances in PostgreSQL—parallel query, smarter partitioning, and just‑in‑time compilation—and the rise of MySQL HeatWave’s integrated HTAP design that folds MPP analytics, in‑engine machine learning, and vector search into a single MySQL service. The net effect is a new performance envelope for OLTP that stretches further into semi‑structured, analytical, and AI‑adjacent territory without abandoning transactional correctness.

This matters now because applications no longer draw clear lines between transactional and analytical behavior. JSON-heavy payloads, vector similarity lookups, and ad hoc aggregations routinely collide with high‑throughput OLTP. PostgreSQL’s tightening execution loop and JSONB capabilities open one path: keep complexity inside a standards‑first core with extensions where needed. MySQL’s answer is different: integrate analytics, ML, and vector capabilities directly alongside InnoDB and expose it all as a unified managed service.

This article examines the architectural shifts behind these approaches, details the execution changes that influence latency and throughput, and contrasts PostgreSQL’s extensible core with HeatWave’s integrated HTAP stack. Readers will learn where each engine’s design tends to excel, which trade‑offs to expect, and how to choose features that align with workload profiles.

Architecture/Implementation Details

PostgreSQL execution pipeline: parallelism, partitioning, and JIT

From v11 onward, PostgreSQL’s execution path incorporated three improvements that reshaped its OLTP and mixed‑workload profile:

• Parallel query execution: Parallel workers can be engaged to process parts of a plan concurrently, expanding the window in which Postgres can push down latency on complex statements while preserving transactional semantics. Specific metrics unavailable, but adoption patterns show this capability materially expanded the feasible workload envelope.
• Improved partitioning: Declarative partitioning and better partition pruning mean fewer tuples scanned and less executor waste for time‑ or key‑ranged data. The practical result is more predictable latency under wide tables or high write rates where partitions confine active working sets.
• Just‑in‑time compilation (JIT): By generating machine code for expression evaluation and tuple deforming in suitable plans, JIT reduces per‑tuple overhead in CPU‑bound operations. The main observable outcome is reduced tail latency on complex queries and higher throughput when the working set is already memory‑resident.

These changes don’t act in isolation; they compound. Partitioning shrinks the data set a plan touches, parallelism fans work out across workers, and JIT trims CPU overhead in the hottest loops. Together, they move an increasing range of mixed OLTP/analytical statements into “good enough” territory on a single engine, especially when paired with high‑performance managed tiers such as Aurora PostgreSQL, Hyperscale (Citus), and AlloyDB.

JSONB mechanics and semi‑structured performance

PostgreSQL’s JSONB pairs a binary‑parsed storage format with a rich set of operators and comprehensive indexing options. In practice, this lets developers express complex filters and projections over semi‑structured data without shipping payloads to an external document store. Specific on‑disk layout details and index type internals are out of scope here; what matters is that indexing supports common access patterns and that operators cover transformation and predicate needs typical of JSON‑centric applications.

Two performance side effects stand out:

• Reduced impedance mismatch: With JSONB embedded into relational plans, applications avoid round‑tripping to secondary systems for semi‑structured filters, benefiting both latency and consistency.
• Index‑backed predicates: Where JSON predicates are selective, appropriate indexing can collapse scans to index‑only operations. Specific benchmark numbers are unavailable, but migration activity toward PostgreSQL for JSON‑heavy workloads underscores the practical impact.

Planner, statistics, and complex SQL

Complex SQL workloads benefit indirectly from the trio of parallelism, partitioning, and JIT. More accurate partition pruning reduces plan bloat, parallel workers shorten wall‑clock time on suitable aggregates and joins, and JIT trims CPU cost per row. While detailed planner and statistics enhancements are not enumerated here, practitioners consistently cite “advanced SQL” and “indexing strategies” as drivers for choosing PostgreSQL in complex query environments. The upshot: a larger share of analytics‑adjacent logic can remain inside the OLTP engine with tolerable latency.

InnoDB steady state and HeatWave’s integrated HTAP

MySQL’s InnoDB continues to deliver the concurrency and durability profile that underpins web‑scale OLTP. The more consequential shift, however, is architectural: MySQL HeatWave unifies three subsystems into a single service alongside InnoDB execution paths:

• MPP analytics: A distributed, in‑memory analytic layer is integrated rather than bolted on, enabling SQL queries to span OLTP data and analytical replicas without exporting data to an external warehouse.
• In‑engine machine learning: HeatWave trains and executes models within the same managed service, eliminating cross‑system ETL for common ML tasks.
• Vector search: HeatWave Vector handles vector ingestion and similarity search natively, co‑located with MySQL relational data.

The integration minimizes operational surface area. Teams that already standardize on MySQL can adopt HTAP and vector capabilities without managing a separate analytical database, pipeline scheduler, or standalone vector index.

Managed service amplification

On clouds, Postgres‑compatible premium tiers extend the execution envelope while keeping PostgreSQL semantics intact: Aurora PostgreSQL and AlloyDB focus on performance and resilience, and Azure Hyperscale (Citus) adds distributed execution and sharding to Postgres. On the MySQL side, HeatWave is available as a unified managed service, including on AWS, bringing its HTAP and vector features to MySQL estates without infrastructure sprawl. These service designs amplify the underlying engine philosophies: extensibility and compatibility for PostgreSQL; integration and consolidation for MySQL HeatWave.

Comparison Tables

Design philosophy and capabilities

Dimension	PostgreSQL core (2018–2026)	MySQL HeatWave (2026)
OLTP execution advances	Parallel query, improved partitioning, JIT reduce CPU and executor overhead; broader mixed‑workload viability (specific metrics unavailable)	InnoDB remains OLTP core; steady concurrency/durability; HTAP handled by integrated HeatWave layer
Semi‑structured JSON	JSONB with rich operators and comprehensive indexing; keeps JSON‑heavy logic in‑engine	JSON supported; HeatWave path emphasizes keeping workloads within MySQL, with JSON where appropriate
HTAP/OLAP	Postgres can push into analytics via extensions and services (Citus/Hyperscale, AlloyDB, Aurora PostgreSQL); still a core‑plus‑extensions model	Integrated MPP analytics inside the MySQL service; no external warehouse required for many scenarios
Machine learning	Typically via external tools or extensions; posture is “compose with ecosystem”	In‑engine ML training/inference within HeatWave, avoiding cross‑system ETL
Vector search	pgvector extension embeds ANN similarity search within PostgreSQL plans	HeatWave Vector provides native vector store and similarity search within the HeatWave service
Scale‑out	Hyperscale (Citus) distributes Postgres; Aurora/AlloyDB provide scale‑up and read scaling	HeatWave provides distributed analytics within the same MySQL service
Managed service options	Aurora PostgreSQL (AWS), Azure Database for PostgreSQL incl. Hyperscale (Citus), Google Cloud SQL for PostgreSQL and AlloyDB	MySQL HeatWave available as a unified service, including on AWS

Where each approach tends to excel

Scenario	PostgreSQL core/compatibles	MySQL HeatWave
Complex SQL over relational + JSON	Strong fit via JSONB operators/indexing and parallel/JIT execution, keeping logic in one engine	Viable; teams may still use JSON features, but HeatWave’s strength shows more in HTAP consolidation
Mixed OLTP with analytics‑adjacent queries	Postgres core plus Citus/Hyperscale or AlloyDB handles distributed/accelerated execution while preserving Postgres semantics	Integrated HTAP lets MySQL‑first teams run analytics and ML without separate systems
Geospatial/time‑series	Ecosystem strength via PostGIS and TimescaleDB; single logical platform	Useful, but less ecosystem concentration than Postgres in these niches
Vector‑enhanced apps	pgvector integrates ANN with relational logic	HeatWave Vector integrates vectors directly with MySQL and HeatWave
Teams already on MySQL	—	HeatWave offers a consolidation path that keeps OLTP, analytics, ML, and vector together
Teams prioritizing extensibility and standards‑first SQL	PostgreSQL’s extension model and compatibility options align well	Possible, but philosophy favors integrated subsystems over extension‑led breadth

Best Practices

Technical decision checklist for architects

Use this checklist to align engine features with workload profiles:

• OLTP core with occasional heavy queries: If complex joins/aggregations and JSON filters occur inside transactions, favor PostgreSQL features that reduce executor overhead—parallel query, partitioning, and JIT—to maintain predictable latency. Consider Aurora PostgreSQL or AlloyDB for additional headroom.
• Semi‑structured data as first‑class citizens: Choose PostgreSQL’s JSONB to centralize JSON operators and index‑backed predicates in the relational engine. Ensure the access patterns are sufficiently selective to benefit from indexing.
• HTAP without extra systems: If your organization is already MySQL‑first and you seek to avoid separate analytic databases, MySQL HeatWave’s integrated MPP analytics and in‑engine ML can consolidate pipelines and reduce operational load.
• Vector search near transactions: If you want vector similarity inside transactional logic, PostgreSQL with pgvector or MySQL with HeatWave Vector both keep embeddings and relational data in one place. Select based on your primary engine and surrounding tooling.
• Distributed or multi‑tenant SaaS: For Postgres‑oriented teams, Azure Hyperscale (Citus) distributes tables/shards while preserving PostgreSQL semantics; it’s a natural path to scale‑out with extension‑led control.

Trade‑offs in design philosophy

• Extensible core (PostgreSQL): You compose capabilities—geospatial with PostGIS, time‑series with TimescaleDB, distribution with Citus, vector with pgvector—under a consistent SQL and wire protocol. This is ideal when you value standards, portability, and the ability to add capabilities incrementally.
• Integrated subsystems (MySQL HeatWave): You accept a single managed surface where analytics, ML, and vector are built into the service. This is compelling when operational simplicity and a single‑engine strategy matter more than extension‑level flexibility.

Tuning and operations guidance

• Keep data locality in mind: JSONB and vector workloads benefit when hot attributes and embeddings align with indexing and memory residency; HeatWave’s in‑memory analytics similarly thrives on well‑partitioned data.
• Validate plan shapes under load: Parallel query and JIT respond to data distributions; test with production‑like cardinalities and skew. In HeatWave, validate that analytic queries reach the integrated layer and do not congest OLTP threads.
• Exploit managed tiers judiciously: Aurora PostgreSQL, AlloyDB, and Hyperscale (Citus) extend performance envelopes without abandoning PostgreSQL semantics; HeatWave on AWS brings integrated HTAP to where many MySQL estates already run.

Transaction models and isolation semantics

Correctness and contention management remain the bedrock of OLTP. While specific isolation‑level implementations and lock manager details are not enumerated here, architects should:

• Model hot‑row contention explicitly: Replicate peak write patterns and verify latency with and without parallel features or HeatWave‑adjacent analytics.
• Probe long‑running query impact: Validate that JIT and parallel execution shorten wall‑time enough to avoid blocking OLTP; in HeatWave, ensure analytical offload keeps transactional threads responsive.
• Audit extension interactions: When layering PostGIS, TimescaleDB, Citus, or pgvector, test transactional behavior under your isolation defaults. Specific engine metrics are unavailable; rely on workload‑level validation.

Conclusion

By 2026, the line between transactional purity and analytical ambition has blurred inside mainstream open‑source relational engines. PostgreSQL tightened its execution loop through parallel query, improved partitioning, and JIT, and paired those gains with JSONB’s operator‑rich, index‑friendly approach to semi‑structured data. MySQL took a different route, consolidating MPP analytics, in‑engine ML, and vector search inside HeatWave to meet HTAP and AI‑adjacent needs without multiplying systems. Both philosophies legitimately extend OLTP boundaries—one through an extensible, standards‑first core and ecosystem, the other through an integrated managed service that keeps everything in one place.

Key takeaways:

• PostgreSQL’s execution advances reduce CPU and executor overhead, expanding the set of mixed OLTP/analytical queries that perform acceptably without leaving the engine.
• JSONB’s operators and indexing support make semi‑structured queries first‑class inside PostgreSQL plans.
• MySQL HeatWave’s integrated MPP, ML, and vector stack offers a consolidation path for MySQL‑first estates seeking HTAP without extra systems.
• Managed tiers amplify engine philosophies: Aurora PostgreSQL, Hyperscale (Citus), and AlloyDB on the Postgres side; HeatWave on the MySQL side.
• Choose based on workload shape and operational priorities: extensibility and standards, or integration and consolidation.

Actionable next steps:

• Inventory JSON and vector access patterns; map them to indexable predicates or integrated vector features.
• Run production‑like load tests with parallel/JIT enabled in PostgreSQL and with HeatWave‑offloaded analytics in MySQL.
• Evaluate managed tiers where you deploy today—Aurora/AlloyDB/Hyperscale for Postgres and HeatWave for MySQL—to gain headroom without architectural churn.

The likely trajectory from here is more of the same—but better. PostgreSQL’s extension ecosystem will keep widening the aperture for specialized workloads, while performance‑focused managed tiers drive down latency. MySQL will continue to enrich HeatWave, further shrinking the operational gap between OLTP, analytics, and AI‑adjacent tasks. For architects, the challenge is no longer “Can a relational engine handle this?” but “Which relational design philosophy aligns best with how we build and operate software?” ⚙️

Sources & References