Twelve months have passed from our last year's analysis of the most popular relational databases used from within Java Virtual Machines. So it is about the time to see whether the landscape has changed.
Without further ado, lets expose the data, extracted from the applications monitored by Plumbr monitoring solution. The data below originates from 618 different companies and 3,172 unique Java Virtual Machines:
The top four vendors being present in more than 10% of the companies were the same as last year. MySQL is still in the lead, albeit the presence is significantly reduced. Last year MySQL was found in 40% of the deployments, this year we found MySQL connections in 30% of the JVMs monitored. Oracle and PostgreSQL have swapped places, but the ratio of JVMs connecting to these databases is approximately the same, 18.78% and 17.41% correspondingly. Microsoft SQL Server comes in on fourth place, with 13.5% of the customers connecting to this database.
Next group of vendors was present in 1-6% of the companies and consisted of HSQLDB, Firebird, H2, Apache Derby, IBM DB2 and SQLite.
Finally, the Other category consists of vendors with less than five deployments in our sample. This included Informix, Vertica, Snowflake and SAP installations.
Careful readers have noticed that the numbers on the chart add up to more than 100%. It is indeed the case, considering the situations where a particular customer of Plumbr was using several different databases in the background. This builds the foundation for the next question we are looking the answer for.
How Many Datasources Are Applications Connecting to?
Another interesting way to look at this dataset is to see how many different data sources an application is typically integrated with. In this data set, the distribution of the JDBC data sources per application looked like the following:
From the above it is clear that in majority of the situations, just a single data source was present in the JVM. More than 60% of the applications integrated with just a single JDBC data source.
On the other end of the spectrum, we find deployments with more than 10 different JDBC datasource integrations. The record holder in this regard managed to integrate with 150 different JDBC data sources from a single application instance.
Analyzing the applications with more than 50 JDBC connections, it became clear these deployments were built on multi-tenancy architectures, segmenting the tenants in datasource level.
How the Data Was Acquired
The information about database vendor used was extracted from calls to the java.sql.Connection.getMetadata().getDatabaseProductName() API from within the JVMs monitored by Plumbr Agents. The number of datasources per application was extracted from the URIs the connections were connecting to. Unique URI was accounted as a different connection.
The data is not biased towards larger deployments. For example, when a particular customer of Plumbr was monitoring 25 JVMs and connecting to MySQL databases from all the 25, it still counted as just one company in the MySQL category, not 25 JVMs.
Additional remarks regarding the dataset used:
- The JVM the information was extracted was
- monitored by Plumbr Agents during June – November 2016;
- use JDBC Type 3 or Type 4 drivers to communicate with the database;
- do at least one call to a database using JDBC API.
- The Agent monitoring the JVM had to be able to communicate with Plumbr SaaS services, meaning that the On Premises installations of Plumbr are not included in this dataset.