Choosing a data platform: what matters more than the vendor

A long aisle between rows of server and equipment racks
Photo: İsmail Enes Ayhan / Unsplash

When an organisation sets out to build a new data platform, the conversation almost always starts with the vendor. Snowflake, Databricks or Microsoft Fabric? Comparison matrices and demos follow, and months can pass before anyone decides.

In our experience, the platform choice matters less than people think. The mature options can all meet most needs. What decides whether the platform creates value are the questions around it – and they are often asked too late.

Start with who will use the data

Before assessing a single vendor, know what the platform is for and who will use it. Management reporting makes different demands than analysts exploring freely. Machine learning needs large amounts of history and often raw data. Regulatory reporting – which in finance is a requirement, not a wish – demands traceability, reproducibility and figures you can stand behind in front of the regulator.

Write down the key use cases, concretely. Who consumes the data, in which tool, how often, and how fresh does it need to be? The answers narrow the choice far more effectively than any vendor feature list.

Three basic directions

Simplified, there are three main directions, and none is best in every situation.

The first is warehouse-first and SQL-centric. The data warehouse sits at the centre, and most of the work is done in SQL. It suits organisations where reporting and analysis dominate and the team is strongest in SQL and data modelling.

The second is lakehouse and notebook-centric. Data lives in open file formats, and much of the work is done in Python and notebooks. It suits situations where machine learning, large volumes or unstructured data matter, and the team is comfortable in code.

The third is a platform tied into an existing Microsoft estate. If you already run Power BI, Azure and Microsoft 365, that brings real benefits: shared identity, familiar tools and fewer integrations.

The boundaries are also blurring as vendors converge. The difference lies more in what comes naturally than in what is possible.

Cost model and cost control

Cloud platforms are mostly priced on consumption. That is flexible, but cost is driven by usage – not by the contract. A badly written query, a job that runs more often than it needs to, or compute that is never switched off can produce surprising bills.

So the question is not just what the platform costs, but how you will control it. Who owns the budget? Are there alerts, limits and visibility per team or use case? Put this in place before usage takes off, not after the first large invoice.

The skills in the team

A platform that does not suit the team will be expensive, however good it is. If your strength is SQL and BI, there is little to gain from a solution that assumes everyone writes Python – and vice versa. Assess honestly which skills you have, which you can realistically build or bring in, and who will run the platform two years from now.

Governance, access and lineage

In finance this is often the most important point, yet it is often left for later. Who has access to which data, and how is that controlled? Can you document where a reported figure comes from, which transformations it has passed through, and who changed the logic? How are personal and sensitive customer data handled?

All the major platforms offer tools for access control and lineage, but tools do no work on their own. Governance is first and foremost a matter of model, ownership and discipline – and it is far easier to build in from the start than to retrofit.

Avoid lock-in where it actually matters

Some lock-in is unavoidable and not necessarily a problem – the point is to know where it hurts. Data in open formats, transformation logic in version-controlled code, and a clear separation between business logic and platform-specific features make it far easier to switch or combine later. That is where it pays to be principled – not in every tooling choice.

A pragmatic way forward

Rather than spending half a year choosing perfectly, start small. Pick one use case with clear value and build it properly: a sound data model, access control, cost control and automated deployment. You will learn more in a few weeks than in months of comparisons, and gain a foundation ready for the next use case.

At Adventis we help organisations – particularly in finance – with exactly this: clarifying the needs, choosing a platform that fits, and building a data foundation that holds up over time. We have no vendor to sell, only an interest in seeing the platform actually put to use.

← Back to insights

Have a project we can help with?