BlogSupportContact Request demo
Intershop Blog
Your hot spot for insights in technology and market trends of digital sales.
Take it from here if digital commerce is your mission, too.

Powerful e-commerce software needs an underlying database that enables an optimal data flow, no matter how much load is on the system. Intershop relied on Oracle for a long time, but with MSSQL another database will soon be able to form the basis of an Intershop Commerce solution.

Custom-fit software is the basis for a powerful online shop. What is the problem of committing to one database provider?

If you are committed to one provider, then that means being dependent. Of course from all the positive features, but also from company decisions such as licensing model changes. Until now, Intershop has relied on Oracle, at least for its commerce management. Our order management system is based on PostgreSQL, our microservices can be deployed to any database. But our core product so far requires Oracle. This is because Intershop products have always been developed for the enterprise market, and we selected Oracle as the leading database provider. Its performance is undisputed, but this choice also implies that the decision for Intershop always entails a decision for an expensive or time-consuming database. Is that what we want?

Some customers do not start from scratch, but already use database systems based on MSSQL for example. These companies already have personnel who are experienced in the administration of these systems. So it is a major hurdle to gain know-how for Oracle.

Our core product, Intershop Commerce Management, will soon no longer be based on Oracle. What are the alternatives?

A few years ago there were phases of evaluation which DB systems are strong enough in terms of their performance and features to support software for high-performance online shops. The first step was to opt for PostgreSQL, but it never went beyond theoretical considerations. Intershop is now a Microsoft Gold Partner and offers a dedicated cloud offering on Azure. The enterprise market is also increasingly relying on Microsoft products. So it is only logical to support the Microsoft database. Following a successful PoC, a task force was set up in Munich to develop a first prototype. Special thanks go to Daniel Heckmann, Ulrich Neidel and Franz Robeller from MS, but also to Carsten Polack and Thomas Bergmann, who made this project possible. The prototype allowed great confidence to adapt our software so that MSSQL can be supported on an equal footing with Oracle.

How can such a change in the software be imagined?

Well, all databases basically speak SQL. However, there is a very high variability here, with different words and concepts.

In the past, Intershop also relied on special Oracle features, for example, XML was stored in the database and accessed in a structured manner. With MSSQL this is also possible, but it differs how this access to data works. Creating tables in the database and the types that are processed there are all things that work differently with various providers. But as long as relational databases are concerned, the underlying basis is defined by similarities. We have to make many small and bigger changes in the code, both complex and filigree at the same time.

However, our code also contains elements which only indirectly affect the database, but are nevertheless specific. Drivers for example. Most of our software is written in Java. This means that we can, in general, work independently of a database. The SQL for the database can be generated with queries and thus tailored to specific database functionalities.

Does this lead to a loss in performance?

The question is justified. A generic database query is certainly not the optimal or the fastest one. It is no coincidence that database providers have developed their products in such a way that particularly demanding jobs also have special high-performance queries. You can't use these details if you're always looking for the smallest common denominator. So our way was to continue to be able to address these peculiarities. But large parts of the code have been adapted so that generic database-independent SQL queries can be used. The neuralgic points, however, have now been newly developed with different queries that are specially adapted to the Oracle or the MSSQL databases. In this way we continue to benefit from the specialties of both DB systems.                  

How long does it take the team to launch a release-ready version?

We have been working on the project for over a year now, and recently our code, which works for Oracle and MSSQL, has been merged with the main branch of our software. A beta version is currently being made available to selected customers. Not for productive systems, but for extensive testing. This aims to derive recommendations as to what knowledge may be required for our customers who already use existing solutions and want to expand. The beta phase will be followed by an optimization and stabilization phase, after which we will be able to offer our core product for everyone either on MSSQL or Oracle.