OLTP and OLAP name the two broad ways databases are used. Online transaction processing handles the running of a business: orders, payments, inventory moves. Microsoft’s architecture guidance defines it as “the management of transactional data by using computer systems,” where systems “record business interactions as they occur in the day-to-day operation of the organization.” OLTP work is dominated by many small, atomic reads and writes that must keep data consistent.
Online analytical processing is the opposite kind of work. Microsoft defines OLAP as “a technology that organizes large business databases to perform complex calculations and trend analysis,” enabling “intricate queries without disrupting transactional systems.” OLAP queries are big aggregations over large amounts of history rather than single-record updates.
The two workloads pull database design in opposite directions. OLTP data tends to be highly normalized with strong consistency and ACID guarantees, tuned for “heavy writes, moderate reads.” OLAP data is “optimized for heavy-read and low-write tasks,” often denormalized into star or snowflake schemas and preserving historical data for time-series analysis. Because of this, the same data is frequently copied from an OLTP system into a separate analytical store.
In practice many systems are a blend. Microsoft notes that “most workloads aren’t entirely OLTP” and that handling both transactions and real-time reporting on one platform is called hybrid transactional and analytical processing (HTAP). But the OLAP/OLTP distinction remains the basic reason warehouses, columnar stores, and ETL pipelines exist alongside transactional databases.