An open data platform for more than 150 users: cheaper than Fabric, comparable with Databricks and Snowflake, far less to manage yourself

The worked example

The example is an organisation with fifty report users and about a terabyte of data. Every night one load of a few hours fetches only the changes. Power BI reads from import models of at most ten gigabytes that refresh once a day. There is a development and a production environment. Spark, machine learning in production and streaming do not occur in it.

Sources arrive through Azure Data Factory in a single Azure SQL database, where all processing happens as plain SQL. Yres drives the loading, keeps the history and writes every change as Parquet files to a data lake on Azure Data Lake Storage Gen2.

The Azure invoice for both environments together comes to about 750 euros a month. The production database is the largest line, because you pay for it by the hour at whatever level it sits on. Yres puts it on a high level when the load starts and back after the last table, so it sits low during the day. The rest of the invoice consists of the Data Factory activities, storage, the key vault and the small database of the development environment. Yres itself costs a fixed amount per month, with no per-user price and no consumption charges; the Advanced package at 674 euros brings the second environment, the change process and the automatic scaling.

The Power BI prices are those of Microsoft's Dutch pricing page on 6 October 2026, with annual billing and excluding VAT. The last line of the table is optional: a small Fabric capacity (F8) that you switch on now and then for an analysis or a notebook on the same Parquet files and pause afterwards. At forty hours a month it costs about 60 dollars.

Cost at a glance

The same scenario on the three other platforms, always with Power BI as the reporting layer. The Yres column is the worked example in euros; the other three are estimates on list prices of 6 October 2026 in dollars, sized realistically and without discount. For Fabric the outcome is firm: a ten-gigabyte import model only refreshes on an F64 capacity, and that capacity must be on while people open reports. For Databricks and Snowflake the amount depends on cluster sizes and hours, so those show a band.

The outcome: against Fabric the Yres setup is well over half cheaper. Against Databricks and Snowflake the amounts are of the same order, with the Yres setup at the low end. The difference sits in the bottom line of the table. Loading Dutch packages, the history, the change process and the monitoring you build and maintain there yourself, and one day a week of a data engineer costs more at a common hourly rate than the whole Yres licence. How the amounts were calculated is in the appendix at the bottom of this page.

Manageability: who does the work?

The cost above is the vendor's bill. The other bill is your own team's: who builds the loading, who absorbs a changed source, who checks in the morning whether everything went well. The table sets side by side per setup what the engine does and what you do, for the eight situations that take the most time in practice. The cells for Fabric, Databricks and Snowflake come from their own documentation on 6 October 2026.

Databricks and Snowflake do supply real building blocks for this: managed connectors, automatic table maintenance, history in declarative pipelines, alerts on failed tasks. The difference with Yres is that you assemble and monitor those building blocks per source, that most of them only work when the source delivers a change stream, and that none of them knows the Dutch packages.

Two environments are part of that. The Advanced package brings a separate development and production environment, each with its own database, Data Factory, storage and key vault. You build only in development. Every edit there is booked automatically by Yres under a change in a project; on release Yres locks the change and checks that it does not rely on work that has not been released yet. Installing on production is then a single action: Yres rolls out the database structure, republishes the pipelines and translates the names per environment. The object history shows per table, view or procedure how it changed across changes, with two versions side by side. On the other three you set up that deployment process yourself with Git and pipelines; the knowledge base describes the Yres change process step by step.

Which functions each setup brings

On the major functions the four setups differ less in what is ultimately possible than in what you have to build yourself to get there. 'Included' means the function works without you building anything for it; 'build yourself' means the platform supplies the building blocks and you supply the solution.

Up to how many users and how much data does this stay cheaper?

The number of users is the first direction of growth. Every extra user costs 20.80 euros in licence; the platform itself does not change. Fabric F64 is flat, about 5,100 dollars a month with a reservation, however many viewers there are. The break-even therefore sits around 175 users. Above that you put only the reporting layer on an F64 capacity, on top of the Yres cost: viewers become free, builders keep Pro, the database and the Parquet files stay where they are. Yres itself stays at 674 euros, however many users are added.

The second direction is the amount of data. The Standard tier of Azure SQL, in which the example runs, goes up to one terabyte per database. That is a terabyte of compressed data: Yres stores the history tables column-oriented, for which Microsoft quotes up to tenfold compression, so that terabyte corresponds to a multiple in source data. Anyone who archives older history to the Parquet files in the data lake stays well under it, while the full history remains available through a combined view. Above that terabyte the setup becomes custom work; that is where this worked example stops.

The third is the work per day. The advantage comes from the load window. With the load of a few hours from the example, the database still sits on the base level more than half the time at one to four refreshes a day. Anyone refreshing every hour fills the day and pays nearly the high level; then a fixed capacity or a warehouse that stops by itself costs the same. If a nightly load does not fit its window even on the highest Standard level, that is the moment for Spark next to the data lake.

What the setup suits and what you put next to it

The setup is made for batch processing with a predictable load window in which only the changes are fetched each night, with reporting from import models. What falls outside that is not a limitation of Yres as a tool but a choice about the environment: you put something next to it, on the same Parquet files in your own data lake.

• Limit: the SQL database is the engine. Anyone who fully reprocesses a terabyte every night instead of only the changes hits the largest level and loses the benefit of scaling down
• Advice: Spark, machine learning at scale or streaming go next to the Yres data lake, in Fabric or Databricks, directly on the same Parquet files; you switch the capacity off when the work is done
• Advice: an F8 next to your Premium-per-user licences for small machine-learning scenarios and notebooks; you connect the Azure storage directly in OneLake with a shortcut, so no copy of the data is needed
• Advice: a Premium-per-user licence for everyone. With it, import models up to a hundred gigabytes run without a capacity and you do not have to track per workspace who may open which report

Appendix: how the amounts were calculated

On Fabric the memory per semantic model decides which capacity you need: ten gigabytes on F32, twenty-five on F64. Because a model needs well over twice its size during a refresh, a ten-gigabyte import model in practice only refreshes on F64. That capacity costs 0.18 dollars per capacity unit per hour: about 8,400 dollars a month without a reservation and 5,000 with a one-year reservation. From F64 the fifty users view with a free licence; the five builders keep Pro. Pausing is only possible outside office hours and not with a reservation. A development workspace runs on the same capacity; a separate F8 for development would cost about 620 dollars a month with a reservation.

For Databricks we count a job cluster of two mid-range nodes loading three hours a night. For the Power BI refresh and ad-hoc questions a serverless SQL warehouse of size Small runs three hours a day. Add a development cluster of sixty hours a month, storage and an ETL tool for bringing in the sources: Data Factory as in the Yres setup, about 150 dollars, or an ELT service that charges per connector. The load flows for AFAS, Exact or SAP you build in it yourself. Together that is about 1,300 dollars a month, plus fifty Premium-per-user licences, because a ten-gigabyte import model needs them here too.

On Snowflake a Small warehouse runs three hours a night for the load, an X-Small four hours a day for the refresh and ad-hoc questions and a Small sixty hours a month for development. Together that is 420 credits at 2.60 dollars in the Standard edition for West Europe; the Enterprise edition charges one and a half times as much. With 23 dollars per terabyte of storage and the same ETL tool that comes to about 1,300 dollars a month in the Standard edition and about 1,800 in Enterprise, plus fifty Premium-per-user licences.

The report users themselves cost no compute in any of the four columns, because they read from import models in Power BI; only the daily refresh touches the warehouse. Anyone choosing DirectQuery on Databricks or Snowflake lets the warehouse run along during office hours: about 600 dollars a month extra on Databricks, about 570 on Snowflake. In the Yres setup reporting does not touch the database, not even with 150 users.

The Yres column contains a full development and production environment with the change process between them. For Databricks and Snowflake the development hours sit in the assumptions, but a second full environment with its own load flows and the setup of the deployment process come on top, in time more than in money. All amounts apply to this scenario: if the data grows, all four columns grow with it, on Fabric possibly to a second F64, on Databricks and Snowflake to more cluster hours and credits, in the Yres setup to a higher database level. The sums for Databricks and Snowflake are estimates; ask them for a calculation of your own.

Frequently asked questions