2.1Bloom · UNot started

What actually changed when you moved to HANA

Reading depth

What you'll learn

HANA changed the storage and execution model — columnar, no implicit sort, snapshot reads, transparent pool/cluster tables — so old assumptions about order and locking no longer hold.

  • Columnar by default — no implicit physical row order to rely on.
  • No implicit sort: order must be requested, or it is arbitrary.
  • SELECT takes no row lock; reads come from an MVCC snapshot.

Your instinct that a SELECT inside a loop is a problem did not become wrong on HANA — it became more right, because the columnar engine rewards set-based access even harder. The conceptual shift to HANA is not 'faster' — it is five structural changes, and every well-known pitfall derives from one of them. Tables are columnar by default, so the row order you used to get implicitly is gone; a result set arrives in whatever order the column-store engine finds cheapest unless you ask for an order.

Reads no longer take row locks, and HANA serves them from an MVCC snapshot — a consistent view as of the statement's start — so concurrent writers don't block your SELECT and you don't block them. Pool and cluster tables were dissolved into transparent tables (BSEG, KONV, CDPOS and friends), so reads against them now behave like any other table but with subtly different cardinality.

Finally the optimizer thinks differently: it favours set-based, projected, pushed-down access and is unimpressed by row-at-a-time loops and AnyDB-era hints. Internalising these five shifts is what turns 'my code broke after the migration' into 'of course it did, and here is why.'

Key points

  • Columnar by default — no implicit physical row order to rely on.
  • No implicit sort: order must be requested, or it is arbitrary.
  • SELECT takes no row lock; reads come from an MVCC snapshot.
  • Pool/cluster tables are now transparent — same SQL, different cardinality.
  • The optimizer rewards set-based, projected access and ignores AnyDB hints.

Examples

Why the same SELECT returns rows in a new order

On AnyDB a clustered B-tree often handed back rows in key order for free; the HANA column store has no such physical order, so without ORDER BY the sequence is whatever the engine picks.

Source notes: clean-core-curriculum §2.1

Ask Claude

Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.