OLTP and OLAP began as two distinct workload types, each with its own storage format and query engine: row-based engines like Postgres and MySQL for transactional work, and columnar systems like ClickHouse or cloud data warehouses for analytics. HTAP systems combine both workloads in one platform, using dual storage formats or query engines to serve transactions and analytics side by side. Examples include SingleStore and TiDB, which either synchronously write to both row and column stores or asynchronously replicate with merge-on-read. Databricks’s LTAP takes a different tack: it links two separate systems—typically a transactional database and a lakehouse or Spark cluster—so that cold data lives in a shared tier without creating a second durable copy. Hot data stays in the OLTP engine, while older, colder data moves transparently into the lakehouse. Beyond the single-vs. multi-system question, the post lays out a matrix of five architecture types: Single Tier (one system, one workload, one copy), Internal Tiering (one system with hot/cold tiers), Hybrid (single system, two workloads, one copy—with “freshness by composition” or “freshness by catch-up” sub-types), Materializing (two systems, two workloads, two copies via ETL or connectors), and Shared Tiering (two systems, two workloads, one shared cold tier). Hybrid-sync systems like SingleStore write both formats in tandem; catch-up designs like TiDB/TiFlash wait for the column store to reach a certain log sequence number before serving analytics. Materializing setups copy data out—Kafka to Iceberg or Postgres to a lakebase—and keep each system dedicated to its workload. Shared Tiering, where LTAP sits, uses a single durable cold store that both systems reference, dialing data overlap up or down depending on cache retention policies. The taxonomy also hints at possible extensions: synchronous shared storage with read-replica or multi-master modes, though those bring their own consistency headaches. There’s another layer in play, too—the logical data model. OLTP favors 3NF; analytics leans on star or snowflake schemas. That gap often pushes architectures toward materialization, since you can’t easily store a Kimball design as a cold tier behind a normalized OLTP store. The post argues that obsessing over “zero copies” misses the point; real systems juggle tiers, formats, models and consistency guarantees to hit cost and performance targets.