Back to overview

31 March 2026

Four database technologies we use at Cube.

Why we sometimes use four different databases within a single project. When you say ‘database’, everyone thinks of the same thing: a place where you store and retrieve data. And that’s true; in the end, it runs on a hard drive, or sometimes even on a RAM memory stick. But as soon as your landscape grows, the data becomes more complex, or you need real-time insights, you’ll soon realise that one type of database isn’t always enough. At Cube, we regularly build solutions in which multiple databases work together. Not because it has to be complicated, but because each type of database excels at something specific. In this article, we’ll take you through the four database technologies we use most frequently and explain when to choose which one.

Jordy ten Elsen - Tech Lead Developer bij Cube - Oldenzaal

Jordy Software Architect

Reading time

8 min

What exactly is a database?

Let’s go back to basics. A database is a system for storing, managing and retrieving data in a structured way. Think of customer details, orders, product information or sensor data. Without databases, every application would be like a goldfish: forgetting everything the moment you pull the plug. But the question isn’t just what data we need to store, but also what we want to achieve with it. Do you want to be able to search, filter or analyse quickly? Does the data need to be stored quickly, or retrieved quickly? Just as you wouldn’t use a screwdriver to hammer in a nail, not every database is suitable for every type of data. That’s why there are different types, each with their own strengths.

MySQL: the reliable all-rounder.

MySQL is a relational database. This means that data is stored in tables with rows and columns, a bit like a well-organised Excel file, but much more powerful and faster. Relational databases are ideal for structured data where the relationships between data are important. Take a web shop, for example: a customer places an order, that order contains products, and each product has a category. You capture those connections using relationships between tables.

When do we use MySQL ?

Websites and web applications (such as CMSs, portals and online shops),
Applications with clear, predictable data structures,
Projects where reliability and speed are essential.

MySQL is also the standard database within our Laravel-ecosysteem .The Laravel and MySQL combination is tried and tested, well documented, and enables us to build applications quickly and reliably. For most projects, MySQL is therefore our starting point.

An example

With a customer portal built on MySQL, it’s all about the power of simplicity and clarity. By linking customers, contracts and invoices through clear relationships, you create a system that always remains logical. It is precisely this relational structure that provides clarity and an overview, no matter how much your dataset grows.

                        // Retrieve customer data along with associated contracts
$customer = Customer::with(“contracts”)->find($id);
 
// MySQL automatically finds the correct relationships
// based on the tables: customers, contracts, invoices

MongoDB: flexible when the structure isn’t yet fixed.

MongoDB is a NoSQL database. Instead of tables with fixed columns, MongoDB stores data in documents, similar to JSON objects. Each document can have a different structure, which makes MongoDB extremely flexible. This is useful when working with data that doesn’t fit neatly into a spreadsheet. Think of product catalogues where each product has different properties, content management systems, or data from external sources that arrives in all sorts of formats.

When do we use MongoDB?

Applications with variable or unpredictable data structures,
Large volumes of unstructured or semi-structured data,
Projects where flexibility in the data model is paramount.

An example

Within a Data Management Platform (DMP), we process data from various sources: a CRM provides customer data in one format, an ERP system in another. MongoDB makes it possible to store that data without first having to force everything into the same mould. In MySQL, you would need to create separate columns or additional tables for each type of product, whereas MongoDB handles this variation flexibly.

                        // A product in MongoDB — each document can be different
{
  ‘name’: ‘XR-500 Heat Pump’,
  ‘category’: ‘climate’,
  ‘specifications’: {
    ‘power_kw’: 5.2,
    ‘energy_label’: ‘A+++’,
    ‘suitable_for’: [“new_build”, ‘renovation’]
  }
}
 
// Another product with a completely different structure:
{
  ‘name’: ‘Mono 400W Solar Panel’,
  ‘category’: ‘energy’,
  ‘certifications’: [‘IEC 61215’, ‘IEC 61730’],
  ‘warranty_years’: 25
}

InfluxDB: built for data that never stops.

InfluxDB is a time-series database, specifically designed for storing and analysing data that flows in continuously with a timestamp. Think of CPU load, temperature sensors, energy consumption or API response times. Whilst MySQL or MongoDB work well for data that you update occasionally, InfluxDB is built for scenarios where new data points are written every second. It is optimised for fast data writing and for writing time-based queries.

When do we use InfluxDB?

Monitoring systems and infrastructure,
Storing incoming sensor and consumption data,
Real-time dashboards with time series.

InfluxDB in practice.

A concrete example from our own work. For Fundaments we have built a consumption engine that collects vCloud infrastructure metrics. Multiple clusters continuously provide data on CPU usage, memory, storage and network capacity. This data is stored in InfluxDB and made available via a REST API to the Data Management Platform, where Filament dashboards visualise the metrics in real-time graphs. In addition, this data is also displayed in the Customer Portal for end users. In InfluxDB, metrics are stored as measurements with tags and fields. A query to retrieve the CPU usage of a virtual data centre might look like this, for example. This provides the average hourly CPU usage over the past week – exactly what you need for a clear dashboard. Try doing that efficiently in MySQL with millions of data points; that’s where InfluxDB really shines.

                        from(bucket: "vcloud_metrics")
  |> range(start: -7d)
  |> filter(fn: (r) => r["_measurement"] == "virtual_datacenter_usage")
  |> filter(fn: (r) => r["_field"] == "cpu_used_mhz")
  |> aggregateWindow(every: 1h, fn: mean)

Elasticsearch: search as a superpower.

Elasticsearch is not strictly a traditional database, but a search and analytics engine. It is built on Apache Lucene and optimised for lightning-fast searching through vast amounts of data, such as full-text search, autocomplete and faceted filtering. Whereas in MySQL you write a query that matches a column exactly, Elasticsearch can search by relevance, synonyms and even handle spelling mistakes. That makes it a perfect complement to your primary database. Data is often populated into an Elasticsearch database from a MySQL database in order to leverage the strengths of each type of database.

When do we use Elasticsearch?

Advanced search functionality in online shops or portals,
Log analysis and monitoring (in combination with the ELK stack),
Applications where users need to be able to search through large datasets quickly.

An example

We have used Elasticsearch on several occasions to build a powerful search function for online shops. Users need to be able to find products quickly based on name, feature or availability, even with thousands of products in the database. Elasticsearch searches multiple fields in milliseconds, corrects spelling mistakes and ranks results by relevance. That is something a traditional database simply cannot do as quickly or intelligently.

                        // Zoekquery in Elasticsearch
GET /products/_search
{
  "query": {
    "multi_match": {
      "query": "fiets met accu en 5 versnellingen",
      "fields": ["naam", "kenmerken"],
      "fuzziness": "AUTO"
    }
  }
}

The power of combination.

In practice, we rarely use these databases in isolation. Within a Data Management Platform, they actually work together. Each type of database does what it does best:

MySQL manages the structured core: customers, contracts, orders and the relationships between them.
MongoDB captures flexible data from external sources that do not fit into a fixed schema.
InfluxDB continuously stores incoming time-series data for monitoring, usage and dashboards.
Elasticsearch makes everything searchable with fast, smart search functionality.

The DMP acts as the central hub that connects all these data sources and makes them accessible to front-end applications, portals and dashboards. That is the core of how we approach data architecture at Cube: not one database for everything, but the right database for the right task.

What each database means for you.

An overview of the four databases and their strengths. You might be thinking: that all sounds rather technical. And it is, but as a client, you don’t need to worry about that. We make those choices for you, based on your situation.

What you will notice:

Better performance: because we use the right database for the right task, your application runs more smoothly.
Scalability: your system grows with you without everything having to be turned upside down.
Lower costs: no unnecessary complexity, just the right tools in the right place.
Future-proof: a well-designed data architecture is easier to expand with new functionality.

We’re happy to help you find the best approach for your specific situation. Whether it’s a new platform, an existing system that needs to work smarter, or a Data Management Platform that brings all your data together. Databases are the invisible foundation underpinning every application. You can’t see them, but you notice immediately if they aren’t set up properly. By carefully selecting which type of database to use where, we at Cube build solutions that not only work today, but will also be able to keep up tomorrow. And that’s exactly the idea: technology that works for you.