SAP HANA moved business logic into memory so analysis could run on live data

Enterprise analytics had a latency tax. Companies copied transactional data into warehouses, prebuilt aggregates, and waited for reports that were already stale by the time executives used them.

SAP HANA attacked the stack itself. Computerworld described the 2010 release as an in-memory engine that held data in RAM rather than reading from disk, attached to ERP systems so transactional data could be analyzed in real time. SAP also chose an appliance model with hardware from multiple vendors rather than one proprietary box.

The technical release explained why it was fast: HANA used an in-memory columnar store for scans, grouping, and aggregation, and embedded procedural calculation in the database kernel. SAP claimed 2 million records scanned per millisecond per core and more than 10 million complex aggregations per second per core on standard Intel processors.

Stop copying data out before asking questions

Keeping data in RAM removed disk latency from the questions business users asked most often.

Column storage made scans and aggregations cheap without maintaining many precomputed aggregates.

Pushing calculations into the database kernel avoided round trips between database and application layers.

The appliance model let SAP tune software and partner hardware together while still avoiding a single-vendor hardware trap.

A speed breakthrough can come from deleting layers: put computation where the scarce movement used to happen.

HANA shipped in late 2010 and became generally available in 2011. It later became the foundation for SAP's S/4HANA strategy, turning the in-memory database from an analytics appliance into the core of SAP's next ERP generation.