---
title: "OLTP"
description: "OLTP (Online Transaction Processing) refers to systems designed for fast, high-concurrency, small read/write transactions — like inserting an order or updating an account balance — typically backed by normalized relational schemas."
canonical: "https://motherduck.com/glossary/oltp/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "DuckDB statements | MotherDuck Docs"
    url: "https://motherduck.com/docs/sql-reference/duckdb-sql-reference/duckdb-statements/"
  - title: "Lovable + MotherDuck Integration | DuckDB Analytics"
    url: "https://motherduck.com/ecosystem/lovable/"
gated_asset:
  title: "DuckLake: The Lakehouse Table Format"
  url: "https://motherduck.com/lp/ducklake-lakehouse-table-format-book-full/"
---

# OLTP

> OLTP (Online Transaction Processing) refers to systems designed for fast, high-concurrency, small read/write transactions — like inserting an order or updating an account balance — typically backed by normalized relational schemas.

## Overview

OLTP systems run the operational side of a business: processing an order, updating an inventory count, recording a login, transferring funds. They're characterized by many short transactions happening concurrently, strict consistency requirements (ACID: Atomicity, Consistency, Isolation, Durability), and schemas normalized to 3NF or beyond to avoid update anomalies and keep writes cheap and safe. Row-oriented storage is typical, since a transaction usually reads or writes a whole row (a full order, a full customer record) at once.

Traditional relational databases like PostgreSQL, MySQL, and SQL Server are the classic OLTP engines. The design priorities are the opposite of an analytical (OLAP) system: OLTP favors fast, isolated, single-row operations over fast full-table scans and aggregations.

### Example

```sql
-- Typical OLTP schema: normalized, small transactions
CREATE TABLE accounts (
    account_id INTEGER PRIMARY KEY,
    balance DECIMAL(12,2)
);

-- A single, fast, ACID transaction
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT;
```

This kind of query — touch one or two rows, commit immediately, thousands of times a second from many concurrent users — is what OLTP engines are built and indexed for.

### OLTP vs. OLAP

Data warehouses don't replace OLTP systems; they consume from them. A typical pipeline extracts data from OLTP source systems (the app's production database), transforms it, and loads it into an OLAP-oriented warehouse for analytics — because running heavy analytical aggregations directly against a production OLTP database risks slowing down the live application.

### DuckDB angle

DuckDB is explicitly not an OLTP engine — it's a columnar, vectorized engine built for OLAP-style analytical scans and aggregations, not for high-concurrency single-row transactional writes. The standard pattern is to extract data from an OLTP system (via a connector, CDC, or periodic export) and load it into DuckDB or MotherDuck for the analytical workloads OLTP databases handle poorly.