€50,000 for Exasol – The Real Question Isn't the Licence

Almost every department has at least one dashboard that should be useful but that hardly anyone opens anymore: it loads too slowly, shows outdated numbers, or two departments argue over which version of the same metric is correct. In these cases, the real problem is rarely the dashboard itself. It sits one level deeper — in the database, in the data model, or somewhere along the path from the source systems to the report.

Part one of this series covered the visibility building block: a clearly scoped BI project built on Tableau Server or Amazon QuickSight. This article goes one level deeper: the data foundation, with Exasol as a possible building block. As a reminder: since July 1, 2026, the direct-award threshold for German federal agencies has been €50,000 net. States and municipalities set their own thresholds independently.

The real guiding question isn't whether €50,000 is enough to buy an Exasol license. It's whether that budget is enough to reliably determine whether a dedicated analytical data foundation would actually solve your reporting problem.

Why Operational Systems Reach Their Limits

Line-of-business systems are built for day-to-day operations — applications, lab orders, payments, or status updates. Complex analysis over long time periods is rarely part of their core job. Yet these are exactly the kinds of queries that often run directly against these systems. The consequences are familiar: dashboards become sluggish, production systems come under additional load, and as data volumes grow, every historical analysis takes longer than the last. Business units resort to their own spreadsheet copies because the official channel is too slow or too rigid.

A dedicated analytics layer separates operational processing from reporting. Data from selected sources is loaded, transformed, structured for business use, and made available to BI tools. This means the production system is no longer burdened by every single query.

What Role Exasol Plays

Exasol positions itself today as the sovereign database for AI agents, built for high-concurrency AI and analytics workloads – but the same architecture works just as well for classic reporting. Depending on the contract model, Exasol runs self-hosted, as SaaS, or, through the partnership with STACKIT, in data centers in Germany and Austria, with data held exclusively within the EU and no exposure to the US CLOUD Act – a natural fit for a company headquartered in Nuremberg. In a typical reporting architecture, Exasol sits between the prepared source data and a BI tool like Tableau. There, data is consolidated, calculation logic standardized, and historical data analyzed, largely decoupled from operational production systems. Tableau connects directly to Exasol via JDBC (Java Database Connectivity) or ODBC (Open Database Connectivity), enabling live analysis even under high concurrency and on large datasets.

If the load process runs only once per night, for example, the dashboard will still show yesterday's figures the next morning — no matter how fast Exasol answers the individual query afterward. How current a dashboard feels is therefore determined as much by the load process as by the database itself.

In the M2 Data Maturity Framework, a centralized data foundation like this is a typical development step: moving away from fragmented data assets toward organized, reusable data processes. Exasol is one possible building block for a centralized data warehouse in that model.

When It's Actually Worth Looking at the Data Foundation

Not every slow dashboard needs a new database. Sometimes a better data model, more efficient queries, or an optimized Tableau workbook is enough. Signs of a deeper problem tend to look more like this: analytical queries are noticeably slowing down the operational line-of-business system; the same data is copied multiple times for different reports; metrics are recalculated separately in every dashboard; or new reporting requests can only be met with yet another one-off solution.

Our assessment: A combined data and performance analysis provides the foundation for this decision. It shows whether Exasol would add real value in your specific case — or whether a smaller, less expensive optimization of the existing environment is already sufficient. We consider this kind of honesty essential to a good starting project, even when the outcome ultimately argues against a larger rollout.

What's Realistically Achievable With up to €50,000

For a larger public authority, this budget usually isn't enough to fully plan, migrate, and roll out an organization-wide data warehouse into production. But for a manageable level of data and integration complexity, the budget is enough for a clearly scoped data domain. Often, significantly less than €50,000 is enough for that.

Examples include:

• Case numbers and processing times for a specific line-of-business system
• Operational data for a public facility
• Service metrics for a citizen portal
• Or a single dashboard with noticeably long load times

The project is deliberately limited to one relevant business area, leaving the organization's other data sources out of scope for now. That keeps the budget from turning into a scaled-down version of a large program, and instead makes it a pilot that enables a well-founded decision based on real data.

Based on our experience, a starting project like this can be broken down into five steps.

• Start with diagnostics: Which reports are especially slow, which queries create the most load, and is the bottleneck in the database, the data model, the connection, or the dashboard itself?
• Next, a data domain is clearly defined: business-relevant, with an accountable business owner, known data sources, and an identifiable bottleneck — large enough to deliver real value, small enough to fit the budget.
• The data is migrated to Exasol and modeled there: Inconsistent naming is harmonized, and recurring metrics are calculated centrally so that no dashboard produces its own version of the same number anymore.
• Tableau or another BI tool is connected to the new data foundation: How current the data needs to be and how much load the systems can handle is decided case by case.
• Finally, the operational foundation: documentation, monitoring of load and query processes, and clearly defined roles and responsibilities for data quality.

Three Approaches, Depending on the Starting Point

Based on our project experience, different starting situations call for different types of pilots.

• A performance pilot is a good fit when an existing dashboard works functionally but suffers from long wait times or unstable refreshes. A limited data set is migrated to Exasol, and load times are measured before and after.
• A data model pilot is the right fit when different departments regularly disagree on differing values for the same underlying figure. Calculations that were previously scattered across individual spreadsheets are centralized and documented in a traceable way.
• A relief pilot is relevant when analytical queries put a noticeable strain on an operational line-of-business system, or can only run outside normal operating hours. This approach specifically removes the reporting load from the production system.

Case Study: Tableau and Exasol at Labor Berlin

A project at Labor Berlin illustrates what the interplay between database, data model, and visualization can look like in practice. This example is included solely to illustrate the technical architecture and is not connected to the new direct-award threshold.

Labor Berlin processes a high volume of lab analyses. At the time, several challenges came together: the production system was strained by reporting queries, the data model was inconsistent, and reporting had hit its performance limits. M2 therefore addressed multiple layers together: migrating the analytical database to Exasol, reworking the data model, switching to live data connections, and optimizing the performance of the Tableau dashboards.

The result: selected dashboards became up to 90 percent faster. This figure applies to this specific project and cannot be generalized to other environments. What's more revealing is what would have been missing without the combination of all these measures: a faster database alone would have done little to fix an inconsistent data model. A new data model alone would still have left the production system overloaded. Only the combination of the Exasol migration, the reworked data model, and live connections produced this result.

A Pilot Needs Measurable Goals

Before a project even starts, it should be clear how success will be measured — for example, by the load time of selected dashboards, the runtime of defined database queries, the load on the operational source system, or the number of manual file transfers that will be eliminated going forward. A pilot is valuable even if its outcome ultimately argues against a larger rollout, because its real purpose is to ground an architecture decision in real data rather than assumptions.

Where our assessment comes from: An Exasol project is more than a database installation. Architecture, data engineering, data modeling, BI integration, and operations all need to come together to produce a result that's actually usable in practice. Our project experience spans database migrations and data warehouse projects, Tableau architectures, performance analyses, and the long-term evolution of existing data platforms. A powerful database alone doesn't answer a business question. Only clear data logic, reliable processes, and a suitable analytics layer make information genuinely usable in day-to-day work.

With Exasol, Too, Total Requirements Are What Count

For licenses, operations, maintenance, and other recurring services, the same principles apply as in the first part of this series: the anticipated total requirement must be realistically assessed. Services that are economically interdependent must not be artificially split into separate contracts. A clearly scoped pilot, limited in both subject matter and time, can fall within the direct-award threshold — as long as it doesn't artificially split up a larger, already-planned overall requirement. If a multi-year production environment with licenses and support is planned from the outset, that total requirement must be taken into account accordingly. The final procurement-law assessment ultimately rests with the responsible contracting authority.

Two Building Blocks, One Shared Goal

Both parts of this series follow the same idea: a limited budget should create a complete, verifiable building block with genuine business value — not just an isolated technology purchase. If there's currently no shared access to existing data, a BI project like the one in part one is often the right first step. If reports already exist but are slow or inconsistent, it's worth looking at the data foundation, as described in this article. If both problems exist at the same time, the data model and dashboard should be considered together from the start. The two building blocks in this series can be freely combined.

If you'd like help identifying whether your bottleneck lies in the dashboard, the data model, or the underlying data foundation, we're happy to help — with no obligation. In a free initial conversation, we'll look together at which reporting process is currently causing the most effort, and which pilot would enable a well-founded decision within your budget.

Those who address their data foundation now will make their next architecture decision based on facts, not guesswork.

Read part one: The Visibility Building Block →