“The last 25 years of commercial DBMS development can be summed up in a single phrase: “One size fits all”. This phrase refers to the fact that the traditional DBMS architecture (originally designed and optimized for business data processing) has been used to support many data-centric applications with widely varying characteristics and requirements.”Michael Stonebraker, Uğur Çetintemel · “One Size Fits All”: An Idea Whose Time Has Come and Gone · 2005 · “One Size Fits All”: An Idea Whose Time Has Come and Gone, ICDE 2005 — rezumat
OLTP touches whole rows a few at a time; OLAP touches a few columns billions of times.
OLTP (transaction processing): thousands of small operations per second, each touching a few whole rows — an order, a customer — and each has to be correct while thousands of others happen at the same time. Hence row storage, B-tree indexes and transaction isolation. OLAP (analytical processing): a handful of large queries, each touching two or three columns across hundreds of millions of rows and summing them. Hence column storage, compression and batch scanning. Stonebraker said it in 2005: the era of one engine for everything was over, and since then columnar, streaming, time-series and document engines have arrived. HTAP systems try to do both in one; the price is complexity and, usually, a columnar copy kept up to date in the background. The practical rule: do not run reports on the production database. An analytical scan on a transactional engine blocks or slows writes and misuses the indexes. A read replica is first aid; the warehouse is the treatment.
Why can't you optimize for both at once? Because the requirements clash at a physical level. A transactional engine reads whole rows, like a waiter bringing the full plate: order, customer, address, everything. Exactly what you want when processing a payment. An analytical report wants only the totals column, across millions of rows. Fetching full plates there would be like buying an entire supermarket shelf to get one loaf of bread. With columns, you read only what you need and compress well, because similar values sit side by side. On rows, that compression is nearly impossible. The choice isn't about taste; it's about how data flows through memory and disk. But what if you genuinely need both in one system? That's where the HTAP compromise comes in.
Why it matters The most common cause of a slow production system is not transaction volume but the morning report that scans the entire orders table.