Choosing a Data Platform: What to Compare When the Feature Lists Match

A selection process reaches its final meeting with a spreadsheet: forty rows of capabilities, three columns of vendors, and a weighted score at the bottom separating the winner from the runner-up by four percent. Eighteen months later the platform is working, and the complaint is about something the spreadsheet never asked — that the nightly load and the morning dashboards fight each other, or that the permission model the security team designed is enforced on one access path and not another, or that the cost is fine but nobody can explain it to finance.

The matrix was not wrong. It answered a question that had stopped being the deciding one. Mature products in this category converge on features, and when every column checks every box, a feature comparison is measuring which vendor’s marketing team enumerated more thoroughly. What separates the options by then is how each one behaves under your requirements, what it costs to be wrong, and what you can carry out if you leave. This article is about comparing those things, and about a procedure that survives contact with a procurement deadline. It is method rather than product news; where product specifics appear, they are marked with the date they were checked. The examples are invented.

Two different comparisons

It helps to name the two things that get confused, because each is legitimate and they answer different questions.

	Feature comparison	Architectural fit
Asks	Does the product have X?	What happens to us when we do X on it?
Evidence	Documentation, a demo, a vendor answer	A run on your data, under your load, with your constraints
Good at	Eliminating products that genuinely cannot do the job	Separating products that can all do the job
Fails when	Everything scores well, or a checked box hides a condition	It is skipped because it takes weeks and a matrix takes a day
Shelf life	Short — gaps close between quarters	Long — it reflects your workload, not the roadmap

The feature comparison is not obsolete. It is the cheap first pass that removes candidates with a real gap, and doing it first is correct. The error is treating it as the whole evaluation, which happens because it produces a number and the alternative produces a judgment. A four percent difference between weighted scores is not a finding; it is the residue of weights someone chose.

A checked box also hides its conditions, which is the more specific failure. “Supports row-level security” is true of every candidate. Whether that security is enforced on every path a reader can take to the data is a different statement, and it is the one that matters to whoever signs off on the control. The matrix has no cell for conditions.

Turning requirements into something testable

Architectural fit is only comparable if the requirements are stated so that an answer can be right or wrong. This problem is old and has a worked solution. The Software Engineering Institute’s Architecture Tradeoff Analysis Method, published in 2000 by Kazman, Klein, and Clements, evaluates an architecture against quality attribute goals using scenarios, and the reason to borrow it here is its output vocabulary: it produces risks, non-risks, sensitivity points, and tradeoff points, gathered into risk themes that threaten business drivers.

That vocabulary is more useful than a score because each term implies a next action. A sensitivity point is a decision that a quality attribute depends on sharply — something to measure. A tradeoff point is a decision that improves one attribute and degrades another — something to decide deliberately, with the loser named. A non-risk is a sound decision whose assumptions have been written down — a concern you can stop carrying, which is worth recording precisely because unrecorded concerns come back every meeting. The method assumes what this article assumes: that architecture involves design tradeoffs among attributes like performance, availability, security, and modifiability, and that these have to be analyzed rather than assumed away.

Practically, that means converting each requirement into a scenario with a stimulus, a context, and a measurable response. The difference is visible immediately.

As usually written	As a scenario you can test
“Must be highly concurrent”	“With the nightly load running, 40 analysts issue dashboard queries within one minute; the 95th percentile response stays under 8 seconds”
“Must support fine-grained security”	“A user restricted to one region queries the table through SQL, a notebook, and a BI report; all three return only that region’s rows”
“Must be cost-controlled”	“A runaway job doubles expected daily spend; it is detected and stopped within an hour, without a human watching a dashboard”
“Must be open”	“Against one pinned snapshot, an engine from another vendor reads our largest table with no export: row counts match, the key sets match, agreed measure totals match, deletes are reflected, and timestamps, decimals, and nulls compare equal”

Each right-hand cell can be attempted during an evaluation and will either happen or not. This is also where the distinction between functional and quality requirements earns its keep: functional gaps are rare among mature candidates, and quality attributes are where the candidates actually differ. Keeping the two separate also protects against the common slide from need to solution described in need, requirement, and design choice — a requirement that names a product feature has already chosen, and the evaluation is then a formality with a paper trail. Writing selection requirements that describe outcomes rather than mechanisms is what keeps the comparison honest.

Keep the set small. Six to ten scenarios that genuinely discriminate are worth more than forty that every candidate passes, and the test for inclusion is whether you can imagine a credible product failing it.

The questions every analytical platform has to answer

Underneath the feature lists, the products in this category are solving the same handful of problems. Comparing the mechanisms they use is more durable than comparing the features, because mechanisms change slowly and imply different operational work.

The table below names six requirements and what each product family uses to meet them, as documented on September 15, 2026. It is a map of where to look, not a ranking — and the right-hand column is the part with a shelf life.

Requirement	What a credible answer must show	Mechanisms, as documented on Sept 15, 2026
Keep one workload from delaying another	A boundary with its own compute, and evidence that crossing it is a deliberate act	Snowflake: separate virtual warehouses, which do not share resources. Fabric: separate capacities, since throttling is applied per capacity. Databricks: separate compute for each workload.
Absorb many concurrent users	That queueing, not execution time, is what the mechanism addresses	Snowflake: multi-cluster warehouses. Fabric: capacity size plus bursting and smoothing, with staged throttling beyond it. Databricks: compute sized and separated per workload.
Enforce access rules on every path	The same restriction applied through SQL, notebooks, and BI — demonstrated, not asserted	Databricks: Unity Catalog, with one metastore per region. Snowflake: roles and ownership, with managed access schemas to centralize grants. Fabric: OneLake security roles, enforced across analytics experiences.
Stop spending before the invoice	A control that acts in advance, and a clear statement of what it does not cover	Snowflake: resource monitors over warehouse credits and their supporting cloud services — not storage, not serverless. Fabric: the capacity SKU itself, with throttling as the backstop. Databricks: compute configuration and policy.
Let another engine read your data	An open format, and a path to the metadata, not just to the files	Open table formats are the common answer: Databricks with Delta, Snowflake offering Iceberg tables, OneLake storing Delta Parquet or Iceberg with metadata virtualization between them.
Be operable by the people you have	Who does the tuning, the upgrades, the access reviews — and whether they exist	Varies more by your organization than by the product, which is why it belongs in the evaluation rather than the datasheet.

Two things are worth drawing out of that table, because they are what a demo will not volunteer.

First, every isolation mechanism has a unit, and the unit is the thing to design against. Whether it is a warehouse, a capacity, or a cluster, the question “what shares this unit, and what happens to the rest when one of them misbehaves” has the same shape everywhere and a different answer in each product. Ask it during the evaluation, not after the first incident.

Second, cost controls have edges. A control that covers the largest component is genuinely useful, and it is not a cap on the bill — the components outside it need a review cadence rather than a threshold. Any vendor will tell you what its control does; the useful question is what it does not cover, and it is a fair question to ask directly.

Portability, nominal and real

“We’re not locked in, we use an open format” is the most common form of comfort in this decision, and it is true in a narrow sense and misleading in a broad one. Open table formats are a real improvement: the specifications are public, more than one engine can read the same table, and the data is no longer hostage to a proprietary file layout. That removes one layer of dependency. It is worth being precise that it is one.

Layer	What holds you	What actually reduces it
Data	A proprietary storage format you cannot read elsewhere	An open table format, plus a way to reach the metadata, not only the files
Logic	SQL dialects, stored procedures, notebooks, orchestration definitions	Keeping transformation logic in a portable layer, and testing that assumption occasionally
Operational	Monitoring, CI/CD, access provisioning, cost reporting, incident runbooks — all built against one product’s surfaces	Usually nothing, honestly. This is the layer people discover during a migration
People	Skills, certifications, hiring pipeline, the internal experts everyone asks	Time, which is the resource a migration has least of

The logic layer deserves a concrete illustration, because SQL feels like the portable part. Microsoft’s own guidance for moving from Azure Synapse dedicated SQL pools to Fabric Data Warehouse, checked on September 15, 2026, documents differences in the T-SQL surface area that may require rewriting parts of the DML, along with data type mappings — and notes that datetimeoffset maps to datetime2, which does not store the time zone offset, so that offset has to be extracted into a separate column. That is one vendor’s SQL moving to the same vendor’s SQL, with a documented silent data loss if nobody checks. Between vendors, expect more rather than less.

None of this argues for avoiding commitment. Every platform choice is a commitment, and refusing to make one has its own cost, usually paid as a lowest-common-denominator architecture that uses nothing well. The argument is for knowing which layers you are committing at, so that interoperability claims can be checked rather than believed, and so that a portability and exit plan is written while there is still leverage to negotiate one. The practical test is simple and rarely run: ask, during the evaluation, what it would take to read your largest table with a different engine, and then have someone try it.

Make the pass condition stronger than a row count, though, because matching counts is weak evidence. A missing row and a duplicated row cancel out, and a value can be read with a different meaning while the count stays identical — a timestamp reinterpreted in another time zone or losing its offset, a decimal read at different precision, a null conflated with an empty string. Pin one snapshot so both engines read the same version, then compare in increasing order of cost: counts first, then the set of keys, then agreed totals for the measures people actually use, then a sample compared column by column. Deletes deserve their own check, since a reader that ignores delete files returns rows the source considers gone. None of this is expensive at evaluation scale, and it is the difference between knowing a table is portable and knowing another engine produced a number.

Cost across the whole life, not the quoted rate

Comparing unit prices across these products is close to meaningless, because the units differ and the same workload consumes different amounts of each. What can be compared is the shape of the spend over the life of the decision, which has three phases that behave differently.

• Entry. Migration, parallel running, rebuilding pipelines and reports, training, and the productivity dip while people learn. Underestimated because it is the phase vendors help with, which makes it feel cheap during the evaluation.
• Running. Compute, storage, data transfer, licenses, and the staff time to operate it. The dominant number, and the only one most evaluations model.
• Exit. Moving data out, including egress charges, rewriting logic, rebuilding the operational layer, and running both systems in parallel until the new one is trusted.

The asymmetry in that list is the part worth arguing about in the decision meeting. Entry cost is paid when the organization has chosen to spend, with budget allocated and attention available. Exit cost is paid when something has gone wrong — a price change, an acquisition, a strategy shift, a capability that never arrived — which is exactly when budget and attention are scarce. A cost model that ignores exit is not neutral about it; it is assuming it away.

This is the ordinary content of total cost of ownership, and the reason it is worth restating is that these platforms make the running number so visible — every product in this category reports consumption in detail — that the invisible phases get crowded out. You do not need a precise exit estimate. You need an order of magnitude and a named owner for the assumption, so that “it would be hard to leave” becomes a number someone is accountable for rather than a feeling in the room.

A procedure that holds up

Most of the damage in these decisions comes from sequence rather than analysis. The following order is unremarkable, and doing it in this order is what makes it work.

• Fix the disqualifiers first, and write down why each one disqualifies. Data residency, a required certification, a hard integration. These are pass/fail and they shorten the list before anyone has a favorite. Writing the reason matters because half of these turn out to be preferences wearing a constraint’s clothes.
• Write the scenarios and agree the weights before seeing any results. Weights chosen after results are a justification, not a method — and everyone involved knows it, which is why the scoring loses authority exactly when it is needed. Fixing them first is what makes a scorecard evidence rather than decoration.
• Run the scenarios on your data, with your people doing the work. A vendor-run proof of concept demonstrates the vendor’s expertise. What you need to learn is what your team can make it do, which is a different measurement and the one you will live with.
• Record the risks and tradeoff points, not just the winner. The chosen product will have weaknesses you knew about; they should be in writing, with whatever mitigation was agreed. This is what stops a known tradeoff from being relitigated as a surprise two years later.
• Write the decision down with the conditions that would reverse it. An architecture decision record that captures context, options, decision, and consequences is the difference between a choice and a fact of nature. Include explicit re-review triggers: a cost threshold, a capability that must ship by a date, a workload that would change the answer.

One framing helps with the weight of it. Not every part of this decision is equally hard to undo, and separating the parts changes how much analysis each deserves. Which platform stores your analytical data is hard to reverse. Which product a single new pipeline is built on is often not, and neither is a reporting tool choice, a notebook convention, or an orchestration decision — provided they were made against the open interfaces rather than the convenient ones. Spend the analysis on the choices that are genuinely hard to unwind, and let the reversible ones be made quickly and revisited.

And when the evaluation ends in a near-tie, take the tie seriously rather than breaking it with a decimal place. A near-tie is information: it says the discriminating requirement has not been found, or that the candidates really are equivalent for your purposes. In the first case, keep looking. In the second, decide on the factors the matrix cannot score — which team can operate it, which vendor relationship you would rather have in a bad quarter, which choice leaves more doors open — and say plainly in the record that that is what you did.

A short checklist

Question	If the answer is unclear
Which requirements could a credible product actually fail?	The evaluation measures enumeration rather than fit
Were the weights fixed before the results came in?	The score is a justification, and everyone in the room knows it
Who ran the proof of concept, and on whose data?	You measured the vendor’s expertise, not your team’s
What is the isolation unit, and what shares it?	Workloads interfere, and the fix is found during an incident
What does the cost control not cover?	Spend accrues in the components nobody set a threshold on
Has anyone actually read your largest table with another engine?	Portability is a claim rather than a tested property
What is the order of magnitude of the exit cost, and who owns that assumption?	The hardest phase is the only one left unmodelled
What would make you revisit this decision, and who is watching for it?	The choice quietly becomes permanent

Questions to explore further

• Take your last platform decision: can you find the record of what was traded away, or only the record of what was chosen?
• Pick your most sensitive access rule and list every path a reader can take to that data. Is the rule enforced on all of them?
• What would it take, in weeks and people, to read your three largest tables with an engine you do not currently use?
• If your platform’s price rose by half next year, what would you actually do — and how long would it take?

References

Product-specific statements were checked on September 15, 2026 and are dated in the text; cloud platform capabilities change, so confirm them against current documentation before relying on them. The evaluation method below is not time-sensitive.

• Rick Kazman, Mark H. Klein, and Paul C. Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004, Software Engineering Institute, 2000
• Software Engineering Institute, Architecture Tradeoff Analysis Method Collection
• Microsoft Learn, Migration Strategy and Planning for Azure Synapse Dedicated SQL Pools to Fabric Migration (documentation date March 16, 2026)