Retrospective note. The original 6 January 2011 date is retained. The June general-availability announcement and later developments below are retrospective commentary.
For forty years, enterprise systems were built around a compromise nobody enjoyed. Transactional databases were tuned for writing records quickly — posting an invoice, booking a receipt, recording a shipment. Analytical queries against that same data were slow enough to interfere with operations, so organizations built a second system: a data warehouse, loaded overnight by extract-transform-load jobs, reported on the following morning. Everybody accepted the delay because the alternative was slowing down the systems that ran the business. SAP HANA proposed removing the compromise. An initial version reached selected customers in late 2010, and general availability was announced by SAP on 21 June 2011; support for SAP's business warehouse product was announced that September for availability by November.[1] By keeping data in main memory, in a column-oriented structure, the system could serve transactions and analytical queries against the same records — which meant that, in principle, the second system was no longer necessary.[2] That is a genuine architectural change. The complications were commercial.
What Actually Improved
The technical claims held up for the workloads they targeted. Reports that had run overnight ran in seconds. Analyses that had been impractical — scanning full transaction history rather than pre-aggregated summaries — became routine. And because the data was not a copy, the answer reflected the current state of the business rather than last night's extract. The second-order effect mattered more than the speed. When a query takes eight hours, you plan around it: you decide in advance what to ask, build a report, schedule it, and consume the output. When it takes eight seconds, you can ask a follow-up question. That changes how people use data, and organizations that got value from in-memory platforms generally got it from the change in behaviour rather than from the reduction in runtime. A third effect was architectural simplification. Aggregate tables, materialised views, index structures and reconciliation jobs existed largely to make disk-based analytics tolerable. Removing them removed a substantial amount of code and a category of overnight batch failures.
What the Business Case Left Out
The difficulties were less about technology than about everything that surrounded it. Hardware was specified, not chosen. In-memory operation at enterprise scale required certified appliances with substantial memory configurations, from a restricted list of vendors, at prices that bore no relationship to commodity server economics. Customers who had spent a decade driving down infrastructure cost found themselves back in a certified-appliance market. Licensing was a separate negotiation with its own logic. Pricing tied to memory capacity behaves differently from pricing tied to users or processors, and it interacts with data growth in a way that produces unwelcome surprises. Organizations that modelled the licence cost on current data volumes, in a system whose value proposition encouraged keeping more history online, understated their future position. The applications had to change to benefit. Running an existing system on a faster database yields a faster version of the same system. Realising the promised value required rewriting reports, redesigning processes to use real-time information, and in many cases moving to a new application version — a programme of work substantially larger than a database migration. Skills were scarce and expensive. A new platform meant new administration, new tuning, new backup and recovery procedures. Early adopters paid a premium for scarce expertise and absorbed the cost of learning on production systems. The strategic lock-in was significant. Adopting a vendor's proprietary database alongside their application layer removed most remaining portability. Whether that mattered depended on how the relationship developed over the following decade — which, for many SAP customers, is precisely the conversation they are still having.
The Question That Was Rarely Asked
Across the in-memory adoption wave, one question separated the successful projects from the expensive ones: which decisions would actually change if this data were current? It sounds trivial. It is not, because the honest answer for many reports is none. A monthly management pack does not improve by being available in real time; it is consumed monthly. A financial close is bounded by approval and reconciliation steps, not by query performance. A board report reflects a period that has ended. The decisions that genuinely benefit from current data are operational and frequent: inventory allocation, credit release, pricing, fraud screening, production scheduling, collections prioritisation. Organizations that identified those specific decisions and rebuilt them around live data got a return. Organizations that migrated the platform and continued running the same monthly reports faster got a faster version of what they already had, at considerable expense.
| Question | Evidence to collect |
|---|---|
| Which decision changes? | Name the operational decision and its owner. |
| What grows? | Test projected data volume and applicable licence terms. |
| What must change? | Include application, skills and process redesign work. |
| What can retire? | Identify genuinely redundant extracts, reports and infrastructure. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for In-Memory and Real-Time Platform Decisions
- Start from the decisions, not the technology. List the specific operational decisions that would change with current data, name who makes them, and estimate what the improvement is worth. If that list is short, the business case is smaller than the vendor's model suggests.
- Model licensing against data growth, not current volume. Memory-based pricing scales with the thing your new platform encourages you to increase. Project three to five years forward, including the history you intend to keep online.
- Price the full stack. Certified hardware, licences, migration, application changes, skills, and parallel running. The database licence is frequently the smallest line.
- Separate migration from transformation, and sequence them. Moving the platform and redesigning processes are different projects with different risks. Attempting both simultaneously is the most common cause of overrun.
- Retire what the new architecture makes redundant. Aggregate tables, extract jobs, reconciliation routines and duplicate reports. If the old machinery survives the migration, you have added a platform rather than replaced one, and your cost base reflects that permanently.
- Test with your own data volumes and query patterns. Vendor benchmarks are run on clean data and favourable workloads. Your reconciliation queries and your twelve years of history are the relevant test.
- Assess the lock-in explicitly. Document what it would take to move away, and accept the position knowingly rather than by default.
- Train the consumers, not just the administrators. The value comes from people asking questions they previously could not. That is a behaviour change, and it requires the same investment as any other.
The Pattern Repeating
In-memory computing became normal. Every major database platform now holds working data in memory, column storage is standard for analytics, and the distinction that justified a separate warehouse has largely dissolved. SAP HANA's architectural argument won. The commercial lesson is the more useful one, because it is being replayed exactly. AI platforms are currently sold on the same structure: a genuine technical advance, a transformative benefit narrative, pricing tied to a consumption dimension that the product encourages you to increase, infrastructure requirements that reverse a decade of cost discipline, and a value case that depends on organizational change the vendor's model quietly assumes will happen. The discipline that worked in 2011 works now. Identify the specific decisions that change. Model the cost against the metric that will grow. Separate the platform from the transformation. And be honest about whether your organization will do the harder half of the work — because the technology, then as now, is the part that arrives on schedule.
Common Questions
When was SAP HANA launched?
An initial version reached selected customers in late 2010, with general availability announced by SAP on 21 June 2011. Support for SAP's business warehouse product was announced in September 2011 for availability that November.
What problem did in-memory databases solve?
They removed the traditional separation between transactional systems optimised for writing records and analytical warehouses loaded overnight, allowing analytical queries to run against current transactional data without degrading operations.
Why did in-memory platform projects often disappoint?
Because running existing reports faster does not change decisions. Value came from rebuilding specific operational decisions around current data, which required application changes, process redesign and behaviour change that were rarely funded alongside the migration.
What should be modelled carefully in an in-memory business case?
Licensing tied to memory capacity against projected data growth, certified hardware costs, application change effort, scarce specialist skills, retirement of redundant warehouse infrastructure, and the strategic lock-in from a proprietary database.
In-Memory Platform Briefing — Outpace works out which of your decisions would actually change with real-time data, models what the platform costs as your data grows, and stops you paying for speed nobody uses.