Hana triumphs, MaxDB lives on

What do the new SAP plans mean for users who have always relied on SAP databases? How should they align their own IT strategy with that of SAP?

There are more and more voices that want to convince users that MaxDB in particular is a discontinued model. Strangely enough, when advice is given to switch DBs, there is often no mention of Hana at all; instead, ASE is recommended as the supposedly obvious migration target.

But the fact is: ASE is not a real alternative to MaxDB, and MaxDB is still a reliable and useful DBMS for years to come.

The late 80s: SQL leaves SAP to the others

At the time R/3 was created in the late 1980s, SAP's database strategy was still clear and simple. At that time, SAP was explicitly not a database manufacturer, but rather relied as an ERP provider on the established SQL database management systems.

Initially, these were only Oracle and Informix, later also IBM DB2 and Microsoft SQL Server.

The fact that Oracle had already entered the market with Financials at the end of the 1980s, thus competing with SAP in the field of applications, was initially dismissed as a "coopetition" that was customary in the market.

Over the years, however, SAP developed into the largest value-added reseller for Oracle - and transferred a considerable amount in the millions to the competitor every year. A dilemma that prompted SAP to change its strategy of database abstinence.

The 90s: SAP's own DB

With ADABAS D from Software AG, SAP brought another database in-house at the beginning of 1992. After R/3 certification in 1994, it was initially positioned as a low-cost alternative to Oracle & Co.

After SAP took over the product rights and a large part of the development team from Software AG in 1997, SAP stopped being a mere reseller of third-party database management systems.

The first SAP-owned DBMS was henceforth offered under the name SAP DB.

SAP's obvious goal here was to stir up competition in the database environment and to break Oracle's dominance of SAP's customer base with its own product.

After sales figures failed to pick up noticeably, SAP released version 7.3 of SAP DB under an open source license in 2000.

2003: Open Source Rebirth

A sales cooperation with MySQL AB followed in 2003. As part of this, the DBMS - from version 7.5 - was offered as "MaxDB by MySQL". Support and further development, however, remained with SAP.

This cooperation came to an end in 2007, and from version 7.6 onwards SAP MaxDB was no longer offered as an open source product. However, SAP decided at that time to offer an alternative to make MaxDB still usable outside of SAP applications: as a free "Community Edition" under a Community License.

To date, MaxDB is available in the form of this free Community Edition - and can thus also be used outside the SAP world.

Because SAP did not want to be perceived as a DB manufacturer for a long time, MaxDB existed largely in obscurity. However, this hardly affected its success.

Despite a lack of push from SAP's marketing and sales, the database has definitely spread. MaxDB enjoys an unbroken high level of acceptance, especially in German-speaking SMEs.

Important reasons for this are the low total cost of ownership (TCO) and silent, reliable operation. SAP customers have at least 27,000 MaxDB servers in use.

Incidentally, this number is many times higher than the SAP ASE installations in the customer base. MaxDB has also become widespread within SAP, with more than 2,500 installations. According to insider information, around half of SAP's internal production systems are based on this DBMS.

SAP new developments on MaxDB

SAP also made new technological developments based on the MaxDB kernel. At the end of the 1990s, for example, SAP liveCache was created as an object-based extension of the MaxDB kernel for the in-memory management of complex objects (i.e. trees and networks) - dedicated to the SAP SCM/APO logistics solution.

Currently, there are still over 5,000 installations of SAP liveCache in the context of Supply Chain Management and Advanced Planning & Optimization.

MaxDB also continues to play a special role in connection with SAP Content Server: without MaxDB, no outsourcing of unformatted content to a database.

No official figures are available on this deployment scenario, but one may assume a few thousand or even more than ten thousand installations. SAP MaxDB may not lead an existence in the spotlight, but this has not harmed the popularity among users.

In fact, the installed base of SAP MaxDB has grown significantly in recent years: by over 50 percent since the beginning of 2013 alone. One of the reasons for this is also reflected in the recent study "Relational OLTP-Midmarket DBMS" conducted by the analysts at "Research in Action": MaxDB enjoys a consistently high level of customer satisfaction.

Sybase brings ASE and IQ

At the end of the first decade of 2000, SAP undertook an acquisition of strategic relevance worth billions: As of July 30, 2010, the Californian database manufacturer Sybase was taken over.

SAP's stated goal was to "reach billions of users" as a result.

Although mobility solutions and access to mobile customers were the main motivation for the acquisition, SAP also brought Sybase's original database products in-house with the deal.

These included OLTP DBMS Sybase Adaptive Server Enterprise (ASE) and data warehouse database Sybase IQ, which featured high OLAP performance due to its column-oriented storage organization.

But the acquisition of DBMS technology was more of a "by-catch" and not a building block of the strategy - not yet officially announced at the time - of wanting to be at the forefront of the database market.

What exactly SAP actually intended to do with the acquired DBMS products is still unclear today. In any case, it was never a declared goal to replace MaxDB with Sybase ASE.

SAP reappears as DB manufacturer

By the middle of the first decade of the new millennium, Hasso Plattner had already succeeded in gaining approval for the realization of his vision of a high-performance, column-oriented in-memory database.

Accordingly, SAP had already secretly bought the Californian software manufacturer Transact in Memory in 2005 and with it the in-memory OLTP database P*TIME.

In 2009, SAP set out to create a new SAP database - a technology mix of the row-store DBMS P*Time, the column-store-based search engine TREX developed years earlier, and MaxDB as the persistence layer.

Initially, this new SAP database was only called New Database or New DB. When it was first delivered in November 2010, it was temporarily called High Performance Analytical Appliance.

Later, it was referred to only by the short form of this name: SAP Hana 1.0.

The future belongs to Hana

Since the introduction of Hana, at the latest, it has been clear that SAP is taking the offensive as a database manufacturer and has declared war on Oracle, the main competitor in this field.

The declared goal here is to free SAP applications from traditional RDBMSs, whether their own or those of competitors. For this reason, SAP is investing primarily in the modern Hana platform and hardly at all in the further development of its classic relational databases.

The consequence of this unequivocal Hana strategy is clear: In the long term, there is no perspective for any of the older SAP databases, neither for MaxDB nor for the Sybase legacies ASE and IQ.

The future of SAP's database is Hana. Those who want to continue to obtain their business applications from SAP will not be able to avoid Hana.

With the announcement of S/4 Hana, the next-generation business suite, SAP SE has once again underscored its claim to assert database sovereignty on its turf.

MaxDB: minimum shelf life 2025

The question remains as to what pressure the SAP focus on Hana is now causing for companies that are currently using MaxDB. None in particular at the moment.

It was only at the beginning of 2015 that SAP extended "Mainstream Maintenance" by five years until the end of 2025 - thus guaranteeing maintenance for at least another ten years.

More often the claim is made that the further development of MaxDB has been discontinued.

This is obviously wrong. For example, Database Studio, the standalone management tool for MaxDB, was recently extended by SAP to include a graphical analysis tool.

Another easy way to give a MaxDB instance a performance boost is to use flash memory-based solid-state disks.

The change from HDD to SSD is of course not a further development of the DBMS in the true sense, but it is now possible because SAP has recently certified the corresponding hardware.

ASE without cost advantage

We often hear that it makes sense to migrate from MaxDB to ASE. After all, each "Hana Runtime Edition for Applications and SAP BW (REAB)" already includes a license for MaxDB and for ASE - so the migration would be possible without any license costs, as would parallel operation of both DBMSs.

However, given SAP's clear focus on Hana, such a migration is not a life-extending measure: ASE's lifecycle is likely to end at the same time as MaxDB's.

ASE proponents usually cite data compression as the main argument for migration. But the American adage still applies: "There's no such thing as a free lunch."

The savings in disk space come at a high price, because ASE requires significantly more computing power. The compression advantage of ASE is ultimately paid for with investments in CPU power.

The backup problem of ASE

From a MaxDB proponent's perspective, ASE's backup concept is one of its biggest weaknesses.

ASE cannot empty the log during a full backup. This means: If the backup takes too long, the logs will overflow and the system will come to a standstill.

In contrast, the online backup facility of MaxDB does not have such restrictions. The recommendation that ASE backups should be made during times of low load simply sounds naive and misses the operational realities.

If migration, then on Hana

So it turns out that ASE is often overrated, while MaxDB's capabilities remain notoriously undervalued.

A gain in functionality can only be achieved when migrating from MaxDB to ASE in a few exposed exceptional cases - for example, when higher compression is a decisive factor.

On the other hand, there are higher licensing and maintenance costs (unless the license is purchased cost-neutrally as part of a Hana Runtime Edition), the necessary training effort, and considerable risks.

Users who use MaxDB not only with ERP but also in the form of liveCache or as part of Content Server would not be able to migrate completely to ASE anyway.

As long as SAP does not migrate its internal, MaxDB-based systems to Hana on a broad front, MaxDB users can sleep soundly. Those who use MaxDB today should stick with it until they feel it is time to switch to Hana.

However, a double migration would be completely absurd. Taking the detour via ASE for the Hana target remains nonsensical.