Glossary/OLTP, OLAP & Workload Types

OLTP (Online Transaction Processing)

OLTP is a database workload class optimized for rapid execution of small, focused transactions that insert, update, or query individual records in operational systems.

OLTP systems power operational applications: e-commerce platforms processing purchases, banking systems handling fund transfers, manufacturing systems tracking order fulfillment. These systems prioritize write performance, consistency, and immediate availability. A transaction inserts an order, updates inventory, and records payment in milliseconds, with strong guarantees that all changes succeed or all fail.

OLTP systems are optimized for row-oriented access patterns. Queries typically affect single or small sets of records identified by primary keys. Indexes on primary and foreign keys accelerate lookups. Normalized schemas eliminate data redundancy but require joins for queries. Database engines like PostgreSQL, MySQL, and Oracle are designed for OLTP, using B-tree indexes, row-oriented storage, and locking mechanisms for consistency.

The challenge of OLTP systems is scaling to high transaction volumes while maintaining consistency. Distributed OLTP systems like CockroachDB and Cassandra replicate data and coordinate transactions across nodes. Sharding distributes transactions by customer ID or other criteria, enabling parallel processing. However, cross-shard transactions introduce latency and consistency challenges.

Key Characteristics

  • Optimize for rapid execution of small, focused transactions
  • Access individual or small sets of records via primary keys
  • Require strong consistency guarantees (ACID properties)
  • Support high concurrency with isolation between transactions
  • Use row-oriented storage and B-tree indexes
  • Normalized schemas to minimize redundancy and update costs

Why It Matters

  • Enable reliable operational systems handling millions of daily transactions
  • Ensure data consistency for critical business operations
  • Maintain availability for user-facing applications
  • Provide responsiveness (sub-second latency) for interactive use
  • Support concurrent operations without corruption or data loss
  • Scale to handle peak transaction volumes

Example

`
-- OLTP transaction: Process e-commerce purchase

BEGIN TRANSACTION;

-- 1. Insert order
INSERT INTO orders (customer_id, order_date, status)
VALUES (12345, NOW(), 'pending')
RETURNING order_id;

-- 2. Update inventory
UPDATE products 
SET quantity_on_hand = quantity_on_hand - 5
WHERE product_id = 789 AND quantity_on_hand >= 5;

-- 3. Record payment
INSERT INTO payments (order_id, amount, method, status)
VALUES (50001, 99.99, 'credit_card', 'processed');

-- 4. Update customer profile
UPDATE customer_profiles
SET last_purchase_date = NOW(),
    lifetime_value = lifetime_value + 99.99
WHERE customer_id = 12345;

COMMIT;

-- All operations succeed atomically or all rollback
-- Isolation ensures other transactions see consistent state
-- Indexes on customer_id, product_id, order_id accelerate lookups
`

Coginiti Perspective

While Coginiti is focused on analytical workloads rather than OLTP, it connects to OLTP systems (Aurora, RDS, Cloud SQL, AlloyDB, Azure SQL, SQL Server, Oracle) as data sources. CoginitiScript pipelines can extract from these operational databases and publish transformed results to analytical platforms using incremental strategies. This ELT pattern keeps OLTP systems dedicated to transactional performance while making their data available for analysis without additional tooling.

Related Concepts

ACID TransactionsOnline Transaction ProcessingRow-Oriented StorageIndex (Database)NormalizationOLAP (Online Analytical Processing)Operational Workload

See Semantic Intelligence in Action

Coginiti operationalizes business meaning across your entire data estate.