What is In-Memory OLTP in SQL Server?
Quick Answer
In-Memory OLTP (codename Hekaton) lets you declare memory-optimized tables that live entirely in RAM with row versioning and lock-free optimistic concurrency, instead of the usual page-and-latch storage engine. Paired with natively compiled stored procedures it can give order-of-magnitude throughput gains for extreme high-concurrency, latency-sensitive workloads.
It's a completely different storage engine inside SQL Server for tables you mark memory-optimized — the whole table lives in memory, uses row versioning instead of locks, so readers and writers don't block each other the way they do with the normal page-based engine. Combined with natively compiled stored procedures, which get compiled to machine code instead of interpreted, it can massively increase throughput for workloads that are dominated by short, highly concurrent transactions — think a session-state table or an ingestion staging table taking thousands of tiny writes a second. It's not something you turn on broadly; it's a deliberate choice for a specific hot table where the normal engine's locking becomes the bottleneck.
- No locks or latches — conflicts are resolved with optimistic multi-version concurrency, so writers never block readers or each other on the same row.
- Best fit: a small hot table taking a huge number of very short transactions (session state, telemetry ingestion, order staging) — not a general-purpose replacement for disk-based tables.
- Trade-offs: memory footprint, feature restrictions in natively compiled procs, and it's a real design commitment, not a flag you flip.