I have been lucky to work across a lot of databases and distributed systems, from traditional ones like Db2, to vector databases like Milvus, and now real-time OLAP such as Apache Doris. Each one makes deliberate trade-offs that suit it to a particular kind of work. As vendors keep coining categories to mark their differences, the labels blur together, and the acronyms start to sound interchangeable. Databricks added the newest one at its June summit, announcing LTAP and Lakehouse//RT, which makes this a good moment for a recap on the database catagories.
The most overloaded word in this market is real-time. Every category now claims it, and each one backs the claim with a different measurement. When an engineer says real-time, I have heard them mean at least 4 different things: data that is current, answers that return fast, service that holds up under thousands of simultaneous queries, and tables that absorb corrections as they happen. A system can deliver one of the four and miss the rest.
This post lays out what OLTP, OLAP, real-time OLAP, HTAP, and LTAP each do, which of those four each category delivers, and how to choose.
The four measurements inside real-time
When talking about real-time analytics, we first need to align on the metrics that matter. Below are four that are commonly reviewed as they are important for the business that real-time analytics serves:
Freshness is the age of the data a query can see. The clock starts when an event happens and stops when a query can return it. The source database holds current data by definition. A warehouse loaded nightly serves answers up to 24 hours old. Streaming ingestion lands rows in seconds.
Query latency is the time from question to answer. This is the number benchmarks measure and marketing quotes, and on its own it says nothing about freshness. A warehouse can answer in 500 ms from data loaded last night: a fast answer to a stale question.
Concurrency is how number of queries the system can sustain at once before latency collapses. A weekly report serves 1 analyst. A dashboard embedded in your product serves every logged-in user. AI raises the requirement again: one natural-language question fans out into dozens of SQL queries as an agent explores the data, so internal analytics starts to generate the traffic of a customer-facing app.
Updates measure how well the system absorbs change after data lands. Fresh data is unsettled data: orders cancel, sensors send corrections, late events arrive out of order, a GDPR deletion request shows up. A system can be fast and fresh on appends and still need a rebuild the moment a record changes.
Each category below is a different bet on which of the four matter most, and a fair answer to “is it real-time?” scores all of them, plus what the bet costs in money and operations.
One boundary note: stream processors and streaming databases transform events in flight, before they land anywhere. Everything below is a system you query after data lands; the layers usually stack, with a stream processor feeding one of these stores.
Where it started: OLTP and OLAP
OLTP (Online Transaction Processing) is the operational core, the database behind ordering, payments, and inventory. Postgres, MySQL, and Db2 are the familiar names. Two choices define it. It stores data in rows, because a transaction reads or writes one whole record, and keeping a record’s fields together with B-tree indexes makes that cheap. And it normalizes, splitting data into many narrow tables so each fact is stored once, which keeps writes small and stops a customer’s address from being copied across thousands of orders.
Scored against the four measurements, OLTP is the perfect real-time system at the scope of a single record. Its data is current by definition, it answers in milliseconds, it serves thousands of writers at once, and processing updates is the job it exists to do. A production system handles well over 10,000 transactions per second at low single-digit millisecond latency.
The scope is the catch. Normalization keeps writes safe, and it is also what makes analysis on the same database painful. A question like top products by region last month lives in no single table. It is scattered across orders, line items, products, and stores, and reassembling it means joining those tables, a job that scans far more data than any transaction and competes with the live workload it runs beside.
OLAP (Online Analytical Processing) is the answer to that, built on the opposite choices. Warehouses and the lakehouse store data in columns, so a query that needs 3 fields out of 50 reads only those 3 and compresses them well. They run large scans across many machines (MPP) with vectorized execution, and they often remodel data into star or snowflake schemas, which is a way of arranging the common joins ahead of time.
Batch OLAP concedes three of the four measurements to win the deepest questions. It answers complex queries over enormous history, and in exchange accepts data that is hours old, concurrency sized for analysts rather than users, and updates that wait for the next load. Its compute model assumes queries are big and infrequent; point it at thousands of small interactive queries and cost climbs first, then latency. The classic shape held for 30 years: a row store for transactions, a column store for analysis, and a nightly ETL pipeline between them.
That nightly pipeline is the freshness gap. Everything that follows is a different attempt to close it.
Three ways to close the freshness gap
HTAP, real-time OLAP, and LTAP are three answers to the same problem: how to get analytical answers on data that has barely finished being written. Analyst Jack Vanlightly, in a June 2026 post proposing a taxonomy for exactly this mess, classifies such systems along four axes of his own: how many systems, how many workloads, when data becomes visible across them, and how many durable copies exist. Those axes separate the three approaches cleanly. HTAP is one system running both workloads. Real-time OLAP is two systems and two copies, with data continuously materialized from one to the other. LTAP is two systems sharing one copy.
HTAP: one engine holding both layouts
HTAP (Hybrid Transactional/Analytical Processing) keeps both jobs inside one system, a design a handful of commercial engines compete on. The engine maintains two copies of the data internally, a row store for writes and a column store for reads, and keeps them aligned.
Vanlightly splits the category by how the columnar side stays fresh, and the split decides what a query can see. Freshness-by-composition systems write both layouts synchronously or reconcile them at query time, so analytics sees the latest committed write. Freshness-by-catchup systems replicate to the column store asynchronously and can hold a query until the columnar side catches up to the write it needs. Either way, HTAP posts the best freshness number of any analytical approach: milliseconds to seconds behind the write, with updates handled natively because the row store is the system of record.
The trade is that two engines inside one product is hard to build well. Each side gives up something to a specialist: query latency and concurrency rarely match a dedicated analytical engine, and the result is often a heavier, proprietary footprint. HTAP fits when very fresh analytics on operational data matters more than peak performance on either side.
Real-time OLAP: a dedicated engine on streaming data
Real-time OLAP keeps the transactional system where it is and stands up a separate analytical engine fed continuously from it. Apache Doris, the open-source project VeloDB builds on, sits here alongside a crowded field of open-source and commercial engines. They keep the columnar, MPP foundation of a warehouse and add what streaming needs: ingestion that makes new rows queryable within seconds, primary-key updates so a changed record does not force a reload, and often an inverted index so search and SQL run in one place.
This is the category that tries to hold all four measurements at once: freshness in seconds, answers in under a second, concurrency in the thousands of queries per second, and updates applied at the storage layer. The combination is the point, because the workloads it serves demand all four together. A fraud screen needs current data and a fast answer. A dashboard embedded in a product needs both of those at the concurrency of the product’s user base. Observability needs them on data that arrives at enormous volume and occasionally corrects itself. These workloads built the category, and agent traffic multiplies the demand. Bain’s analysts, reading the 2026 Databricks summit, put the shift plainly: a dashboard could run hours stale because a human understood the lag, but an autonomous agent acting on data has no such margin. Software asking the questions pushes query volume up and freshness tolerance down at the same time, and that combination of requirements is the one this category was engineered for.
Within the category, engines diverge on two of the four measurements, and the divergence is worth testing before you commit. Joins gate query latency for any normalized model. Much of the category grew up on denormalized wide tables, asking you to pre-join data before it lands, which is fast until a dimension changes or a new question needs a table you never flattened. Doris took the other path and invested in distributed joins with a cost-based optimizer, so a normal multi-table model still returns sub-second results. Updates split the field the same way. Doris resolves primary-key upserts at write time through merge-on-write, so queries never see two versions of a row; engines that reconcile versions at read time make every query pay for the settled answer. If your data changes after it lands, these are the spec-sheet lines to test.
The limits are honest ones. A real-time OLAP system is not a system of record. In Vanlightly’s terms it is a materializing architecture, two systems and two durable copies, and the pipeline between them is yours to run. Its freshness floor is the ingestion path, seconds rather than the milliseconds of a synchronous HTAP write. And it is overkill for a quarterly report. Its home is sub-second analytics on data that is seconds old, served to many consumers at once.
LTAP: two systems sharing one copy
LTAP (Lake Transactional/Analytical Processing) takes the same goal as HTAP, transactions and analytics over one set of data, and moves the unification into the storage layer of the lakehouse: a transactional database and a lakehouse read and write a single copy of data in open formats, with no pipeline between them. Databricks coined the term in June 2026, pairing Lakebase (a serverless Postgres) with the lakehouse under Unity Catalog governance, and added a new engine, Reyden, to run analytics on the shared tables through Lakehouse//RT.
Scored on the four measurements, LTAP leads with a fifth: copies. The freshest write lands in Postgres first and reaches the shared copy afterward, which is why Vanlightly files it under shared tiering and calls it fundamentally asynchronous. Updates live where they always did, in Postgres. Query latency and concurrency rest on Databricks' own benchmarks for Reyden, sub-100 ms at 12,000 queries per second, quoted for a product that is in beta and read-only as of this writing, with LTAP itself still listed as coming soon. What the architecture clearly does deliver is governance and simplicity: one governed copy in open formats across both workloads.
How fresh do you actually need
The useful move is to treat each measurement, freshness above all, as a business decision with a number attached, because fresher data costs real money at every step. Second-level freshness adds nothing to a quarterly review. An hour-old number is useless to a fraud screen or an agent about to act. Between those poles, be honest about which decisions ride on the data and how stale they can run before they go wrong.
The same discipline applies to the other three. Sub-second latency matters when a human is waiting on a page or an agent is mid-loop, and matters little for a report nobody reads before 9 am. Concurrency comes from counting consumers, and the count now includes software. Update requirements come from your data: append-only clickstreams forgive almost any engine, while mutable orders punish the wrong one.
Ecosystem usually casts the deciding vote
On paper this is a capability choice. In practice the deciding factor is often the stack a team already runs, because the cheapest real-time architecture is usually the one that fits the formats, governance, and skills already in place.
The patterns are fairly consistent. A team standardized on the Databricks lakehouse, with data in Delta and governance in Unity Catalog, will find Lakehouse//RT and LTAP the natural path, since the data and permissions already live there.
A team whose reporting runs on a batch cloud warehouse tends to add a real-time engine beside it rather than replace it. An organization that values open source, self-hosting, or low cost at high concurrency leans toward Apache Doris.
A shop whose center of gravity is a Postgres or MySQL estate usually keeps OLTP as the system of record and feeds a downstream analytical system. None of these is the single correct answer, and a fair evaluation weighs switching cost, existing contracts, and team familiarity alongside the benchmark, because those often matter more.
How to pick the database that is right for you
Start from the decision you need to make. Ask which of the four requirements it carries: how fresh the data must be, how fast the answer must come, how many consumers ask at once, and how much the data changes after it lands. Then weigh the gap between that and what you already operate. The tree captures category logic in a few questions.
The acronyms will keep multiplying, and more hybrids are coming. The four measurements underneath them do not change, and neither does the final question: how much are you willing to trade, in performance, cost, and complexity, to move each one closer to now.
Where Apache Doris fits
Events must be queryable seconds after they occur, and Doris ingests from streams continuously to meet that requirement. Answers must return in under a second on a normalized multi-table model, which is what the distributed joins and the cost-based optimizer are for.
Thousands of people, or agents, ask at once. And the data keeps changing after it lands: merge-on-write resolves a primary-key upsert before any query sees it, so a corrected record is simply the record. The same engine carries an inverted index, so log search, full-text filters, and SQL analytics run in one place. That is the shape of customer-facing analytics, in-product reporting, observability, fraud and risk screens, and the context pipelines that feed AI agents.
The boundaries from earlier hold. Your system of record keeps the transactions, and deep, cold history can stay in the warehouse or the lakehouse. Doris earns its place in the seconds-fresh, sub-second, high-concurrency middle, as an extra copy with a clear reason: it answers the queries the other systems cannot.
Apache Doris is an Apache Software Foundation project with an active contributor community. If the profile above looks like your workload, start where the project lives: the code is on GitHub, and the community channels take questions from first evaluation onward. And if you would rather test the workload than operate the cluster, VeloDB Cloud is the managed service with a 30-day free trial and no credit card required.
