![\"\"](\"https:\/\/e3mag.com\/wp-content\/uploads\/2026\/03\/banner_bdc_2026_1200x150.jpg\")
<\/a><\/div><\/div>\nFakt ist aber: ASE ist keine wirkliche Alternative zu MaxDB, und MaxDB stellt noch auf Jahre ein verl\u00e4ssliches und sinnvoll nutzbares DBMS dar.<\/p>\n
Die sp\u00e4ten 80er: SQL \u00fcberl\u00e4sst SAP den anderen<\/h3>\n
Zum Zeitpunkt der Entstehung von R\/3 Ende der 1980er-Jahre war die Datenbankstrategie von SAP noch klar und einfach. SAP war damals ausdr\u00fccklich kein Datenbankhersteller, sondern setzte als ERP-Anbieter auf die etablierten SQL-Datenbank-Management-Systeme.<\/p>\n
Anf\u00e4nglich waren das nur Oracle und Informix, sp\u00e4ter auch IBM DB2 und Microsoft SQL Server.<\/p>\n
Der Umstand, dass Oracle mit Financials bereits Ende der 1980er-Jahre auf den Markt kam und damit SAP auf dem Gebiet der Applikationen Konkurrenz machte, wurde zun\u00e4chst als markt\u00fcbliche \u201eCoopeti\u00adtion\u201c abgetan.<\/p>\n
Im Laufe der Jahre entwickelte sich SAP jedoch zum gr\u00f6\u00dften Value Added Reseller f\u00fcr Oracle \u2013 und \u00fcberwies j\u00e4hrlich einen betr\u00e4chtlichen Millionenbetrag an den Wettbewerber. Ein Dilemma, das SAP dazu bewog, bei ihrer Strategie der Datenbankabstinenz umzusteuern.<\/p>\n
Die 90er: SAP-eigene DB<\/h3>\n
Mit ADABAS D von der Software AG holte sich SAP Anfang 1992 eine weitere Datenbank ins Haus. Nach der R\/3-Zertifizierung 1994 wurde sie zun\u00e4chst als kosteng\u00fcnstige Alternative zu Oracle & Co. positioniert.<\/p>\n
Nachdem SAP 1997 dann die Produktrechte und einen Gro\u00dfteil des Entwicklungsteams von der Software AG \u00fcbernommen hatte, h\u00f6rte SAP auf, blo\u00dfer Reseller fremder Datenbank-Management-Systeme zu sein.<\/p>\n
Das erste SAP-eigene DBMS wurde fortan unter dem Namen SAP DB angeboten.<\/p>\n
Das offenkundige Ziel von SAP war es dabei, den Wettbewerb im Datenbankumfeld anzufachen und durch das eigene Produkt die Dominanz von Oracle in der SAP-Kundenbasis zu brechen.<\/p>\n
Nachdem die Absatzzahlen nicht sp\u00fcrbar anziehen wollten, ver\u00f6ffentlichte SAP im Jahr 2000 die Version 7.3 von SAP DB unter einer Open-Source-Lizenz.<\/p>\n
2003: Open-Source- Wiedergeburt<\/h3>\n
2003 folgte eine Vertriebskooperation mit MySQL AB. In deren Rahmen wurde das DBMS \u2013 ab Version 7.5 \u2013 als \u201eMaxDB by MySQL\u201c angeboten. Support und Weiterentwicklung verblieben jedoch bei SAP.<\/p>\n
Diese Kooperation wurde 2007 sang- und klanglos beendet, und von der Version 7.6 an wurde SAP MaxDB auch nicht mehr quelloffen angeboten. Allerdings entschied sich SAP damals, eine Alternative zu offerieren, um MaxDB au\u00dferhalb von SAP-Anwendungen weiterhin nutzbar zu machen: als kostenlose \u201eCommunity Edition\u201c unter einer Community License.<\/p>\n
Bis heute ist MaxDB in Form dieser kostenlosen Community Edition erh\u00e4ltlich \u2013 und damit auch au\u00dferhalb der SAP-Welt einsetzbar.<\/p>\n
Weil SAP lange Zeit gar nicht als DB-Hersteller wahrgenommen werden wollte, fristete MaxDB seine Existenz weitgehend im Verborgenen. Dem Erfolg hat das allerdings kaum Abbruch getan.<\/p>\n
Trotz fehlendem Push durch Marketing und Vertrieb von SAP hat sich die Datenbank durchaus verbreitet. Vor allem im deutschsprachigen Mittelstand erfreut sich MaxDB ungebrochen hoher Akzeptanz.<\/p>\n
Wichtige Gr\u00fcnde daf\u00fcr sind die g\u00fcnstigen Gesamtbetriebskosten (neudeutsch \u201eTCO\u201c) und ein ger\u00e4uschloser, zuverl\u00e4ssiger Betrieb. Bei SAP-Kunden sind mindestens 27.000 MaxDB-Server im Einsatz.<\/p>\n
Diese Zahl ist \u00fcbrigens um ein Vielfaches h\u00f6her als die der SAP-ASE-Installationen in der Kundenbasis. Auch SAP-intern hat sich MaxDB mit mehr als 2.500 Installationen weit verbreitet. Insider-Informationen zufolge basiert rund die H\u00e4lfte der SAP-internen Produktionssysteme auf diesem DBMS.<\/p>\n
SAP-Neuentwicklungen auf MaxDB<\/h3>\n
Auf Basis des MaxDB-Kernels nahm SAP auch technologische Neuentwicklungen vor. So entstand Ende der 1990er-Jahre SAP liveCache als objektbasierte Erweiterung des MaxDB-Kerns f\u00fcr das In-Memory-Management komplexer Objekte (i. e. B\u00e4ume und Netze) \u2013 dediziert f\u00fcr die Logistikl\u00f6sung SAP SCM\/APO.<\/p>\n
Derzeit existieren noch \u00fcber 5.000 Installationen von SAP liveCache im Kontext von Supply Chain Management und Advanced Planning & Optimization.<\/p>\n
Auch im Zusammenhang mit SAP Content Server spielt MaxDB nach wie vor eine besondere Rolle: ohne MaxDB keine Auslagerung von unformatiertem Content in eine Datenbank.<\/p>\n
\u00dcber dieses Einsatzszenario sind zwar keine offiziellen Zahlen verf\u00fcgbar, aber man wird von einigen tausend oder sogar mehr als zehntausend Installationen ausgehen d\u00fcrfen. SAP MaxDB f\u00fchrt vielleicht keine Existenz im Scheinwerferlicht, aber dem Zuspruch der Anwender hat das nicht geschadet.<\/p>\n
In den vergangenen Jahren ist die installierte Basis von SAP MaxDB sogar deutlich gewachsen: allein seit Anfang 2013 um \u00fcber 50 Prozent. Einer der Gr\u00fcnde daf\u00fcr spiegelt sich auch in der k\u00fcrzlich durchgef\u00fchrten Studie \u201eRelational OLTP-Midmarket DBMS\u201c der Analysten von \u201eResearch in Action\u201c wider: MaxDB erfreut sich einer anhaltend hohen Kundenzufriedenheit.<\/p>\n
Sybase bringt ASE und IQ mit<\/h3>\n
Zum Ende der ersten Dekade 2000 unternahm SAP eine milliardenschwere Akquisition von strategischer Relevanz: Per 30. Juli 2010 wurde der kalifornische Datenbankhersteller Sybase \u00fcbernommen.<\/p>\n
Erkl\u00e4rtes Ziel von SAP war es, dadurch \u201eMilliarden von Nutzern zu erreichen\u201c.<\/p>\n
Wenngleich die Mobility-L\u00f6sungen und der Zugang zu Mobilfunk-Kunden das Hauptmotiv f\u00fcr die \u00dcbernahme bildeten, holte sich SAP mit dem Deal auch die origin\u00e4ren Datenbankprodukte von Sybase ins Haus.<\/p>\n
Dazu geh\u00f6rten OLTP-DBMS Sybase Adaptive Server Enterprise (ASE) und die Datawarehouse-Datenbank Sybase IQ, die sich aufgrund ihrer spaltenorientierten Spei\u00adcherorganisation durch hohe OLAP-Performance auszeichnete.<\/p>\n
Aber die Akquisition von DBMS-Technologie war eher \u201eBeifang\u201c und kein Baustein der \u2013 seinerzeit noch nicht offiziell verk\u00fcndeten \u2013 Strategie, im Datenbankmarkt an vorderster Front mitmischen zu wollen.<\/p>\n
Was genau SAP mit den erworbenen DBMS-Produkten eigentlich vorhatte, ist bis heute unklar. Jedenfalls war es nie ein erkl\u00e4rtes Ziel, MaxDB durch Sybase ASE abl\u00f6sen zu wollen.<\/p>\n
SAP tritt wieder als DB-Hersteller auf<\/h3>\n
Schon zur Mitte der ersten Dekade des neuen Jahrtausends war es Hasso Plattner gelungen, Zustimmung zur Realisierung seiner Vision einer hochperformanten, spaltenorientierten In-Memory-Datenbank zu finden.<\/p>\n
Entsprechend hatte SAP schon 2005 insgeheim den kalifornischen Softwarehersteller Transact in Memory und damit die In-Memory-OLTP-Datenbank P*TIME gekauft.<\/p>\n
2009 machte man sich bei SAP daran, eine neue SAP-Datenbank aus der Taufe zu heben \u2013 als Technologiegemenge aus dem Row-Store-DBMS P*Time, aus der bereits Jahre zuvor entwickelten, Column-Store-basierenden Suchmaschine TREX und aus MaxDB als Persistenzschicht.<\/p>\n
Zun\u00e4chst f\u00fchrte diese neue SAP-Datenbank nur den Namen New Database bzw. New DB. Bei ihrer ersten Auslieferung im November 2010 trug sie vor\u00fcbergehend den Namen High Performance Analytical Appliance.<\/p>\n
Sp\u00e4ter wurde sie nur noch mit der Kurzform dieses Namens bezeichnet: SAP Hana 1.0.<\/p>\n
Die Zukunft geh\u00f6rt Hana<\/h3>\n
Sp\u00e4testens seit der Vorstellung von Hana ist es eindeutig: SAP tritt offensiv als Datenbankhersteller in Erscheinung und hat Oracle, dem Hauptwettbewerber auf diesem Gebiet, den Kampf angesagt.<\/p>\n
Erkl\u00e4rtes Ziel ist es dabei, SAP-Anwendungen von traditionellen RDBMS zu befreien, seien es die eigenen oder die der Wettbewerber. Aus diesem Grund investiert SAP schwerpunktm\u00e4\u00dfig in die moderne Hana-Plattform und kaum noch in die Weiterentwicklung ihrer klassischen relationalen Datenbanken.<\/p>\n
Die Konsequenz aus dieser unmissverst\u00e4ndlichen Hana-Strategie ist klar: Langfristig betrachtet gibt es f\u00fcr keine der betagteren SAP-Datenbanken eine Perspektive, weder f\u00fcr MaxDB noch f\u00fcr die Sybase-Erbschaften ASE und IQ.<\/p>\n
Die Datenbankzukunft der SAP hei\u00dft Hana. Wer seine betriebswirtschaftlichen Anwendungen weiter von SAP beziehen will, kommt an Hana nicht vorbei.<\/p>\n
Mit der Ank\u00fcndigung von S\/4 Hana, der Business Suite der n\u00e4chsten Generation, hat die SAP SE nochmals ihren Anspruch unterstrichen, auf ihrem Turf die Datenbankhoheit durchzusetzen.<\/p>\n
MaxDB: Mindesthaltbarkeit 2025<\/h3>\n
Bleibt die Frage, welchen Handlungsdruck die SAP-Ausrichtung auf Hana jetzt f\u00fcr Unternehmen verursacht, die derzeit MaxDB einsetzen. Aktuell keinen besonderen.<\/p>\n
Erst Anfang 2015 hat SAP die \u201eMainstream Maintenance\u201c um f\u00fcnf Jahre bis Ende 2025 verl\u00e4ngert \u2013 und garantiert damit die Wartung f\u00fcr mindestens weitere zehn Jahre.<\/p>\n
H\u00e4ufiger wird die Behauptung vorgetragen, die Weiterentwicklung von MaxDB sei eingestellt.<\/p>\n
Das ist offensichtlich falsch. So wurde beispielsweise Database Studio, das Standalone-Management-Tool f\u00fcr MaxDB, von SAP j\u00fcngst um ein grafisches Analysetool erweitert.<\/p>\n
Eine weitere einfache M\u00f6glichkeit, einer MaxDB-\u00adInstanz einen Performance-Boost zu verpassen, stellen Flash-Speicher-basierende Solid-State-Disks dar.<\/p>\n
Der Wechsel von HDD auf SSD ist nat\u00fcrlich keine Weiterent\u00adwicklung des DBMS im eigentlichen Sinn, er wird aber jetzt m\u00f6glich, weil SAP j\u00fcngst die entsprechende Hardware zertifiziert hat.<\/p>\n
ASE ohne Kostenvorteil<\/h3>\n
Des \u00d6fteren ist zu h\u00f6ren, eine Migration von MaxDB auf ASE sei sinnvoll. Immerhin ist in jeder \u201eHana Runtime Edition for Applications and SAP BW (REAB)\u201c bereits jeweils eine Lizenz f\u00fcr MaxDB und f\u00fcr ASE enthalten \u2013 die Migration w\u00e4re also lizenzkostenneutral m\u00f6glich, ebenso wie der Parallelbetrieb beider DBMS.<\/p>\n
Angesichts der eindeutigen Fokussierung von SAP auf Hana stellt aber eine solche Migration keine lebensverl\u00e4ngernde Ma\u00dfnahme dar: Der Lebenszyklus von ASE d\u00fcrfte zeitgleich mit dem von MaxDB zu Ende gehen.<\/p>\n
Als Hauptargument f\u00fcr eine Migration f\u00fchren ASE-Bef\u00fcrworter meist die Datenkomprimierung an. Aber es gilt immer noch das amerikanische Sprichwort: \u201eThere\u2019s no such thing as a free lunch.\u201c<\/p>\n
Die Ersparnis an Plattenplatz ist teuer erkauft, weil ASE eine deutlich h\u00f6here Rechenleistung erfordert. Der Komprimierungsvorteil von ASE wird letztlich mit Investitionen in CPU-Power bezahlt.<\/p>\n
Das Backup-Problem von ASE<\/h3>\n
Aus Sicht eines MaxDB-Bef\u00fcrworters ist das Backup-Konzept von ASE eine seiner gr\u00f6\u00dften Schwachstellen.<\/p>\n
ASE kann w\u00e4hrend einer Vollsicherung das Log nicht leeren. Dies bedeutet: Wenn das Backup zu lange dauert, laufen die Logs \u00fcber und es kommt zu einem Systemstillstand.<\/p>\n
Im Unterschied dazu kennt die Online-Backup-\u00adEinrichtung von MaxDB derartige Beschr\u00e4nkungen nicht. Die Empfehlung, man solle ASE-Backups doch in Zeiten geringer Belastung machen, klingt schlicht naiv und geht an den betrieblichen Realit\u00e4ten vorbei.<\/p>\n
Wenn Migration, dann auf Hana<\/h3>\n
Es zeigt sich also, dass ASE h\u00e4ufig \u00fcbersch\u00e4tzt wird, w\u00e4hrend die F\u00e4higkeiten von MaxDB notorisch unterbewertet bleiben.<\/p>\n
Ein Gewinn an Funktionalit\u00e4t l\u00e4sst sich bei einer Migration von MaxDB zu ASE nur in wenigen exponierten Ausnahmef\u00e4llen erzielen \u2013 beispielsweise wenn die h\u00f6here Komprimierung ein entscheidender Faktor ist.<\/p>\n
Dagegen stehen h\u00f6here Lizenz- und Wartungskosten (sofern die Lizenz nicht im Rahmen einer Hana Runtime Edition kostenneutral erworben wird), der notwendige Ausbildungsaufwand sowie betr\u00e4chtliche Risiken.<\/p>\n
Anwender, die MaxDB nicht nur mit ERP, sondern auch in Form von liveCache oder im Rahmen von Content Server einsetzen, k\u00f6nnten sowieso nicht vollst\u00e4ndig zu ASE migrieren.<\/p>\n
Solange SAP ihre internen, MaxDB-basierenden Systeme nicht auf breiter Front nach Hana migriert, k\u00f6nnen MaxDB-Anwender ruhig schlafen. Wer heute MaxDB einsetzt, sollte so lange dabei bleiben, bis ihm der Umstieg auf Hana geboten scheint.<\/p>\n
Eine zweifache Migration w\u00e4re indes v\u00f6llig abwegig. F\u00fcr das Ziel Hana den Umweg \u00fcber ASE zu nehmen, bleibt unsinnig.<\/p>\n