The premise
The data warehouse category was supposed to be the layer that compounded competitive advantage. Modern columnar storage, cheap compute, elastic scaling — the architecture promised that every team could query every table without the platform team becoming a bottleneck. Snowflake productised that promise faster than anyone else, and the product is excellent.
The bill is also excellent. Snowflake's consumption pricing scales linearly with the queries you run on the data you already collected. The Cortex AI layer adds per-LLM-call pricing on top. The Data Cloud surface bills per record shared. Every product the organisation builds on Snowflake adds a recurring cost that does not retire when the business case for that product retires.
This is the conversation Middle East data engineering leaders are starting to have at internal architecture reviews. Not because Snowflake is a bad platform — it is one of the best in the category — but because the long-run economics of consumption pricing on the organisation's own data have become visible in a way they were not three renewals ago.
The architectural answer is open formats. The commercial answer is portability. The operational answer is a phased migration that takes nothing offline and proves the economics before the commitment.
Why this is the next migration crisis
Three trends are converging.
Trend one — the consumption meter compounds. Snowflake spend grows with usage. The product is built to encourage usage. The two together mean the spend curve bends in one direction over the life of a typical enterprise contract. We have seen Middle East clients triple their Snowflake spend over three years against a roughly flat workload footprint, as the catalogue of teams using the warehouse expanded and the per-team usage grew.
Trend two — Cortex AI added a second meter. Cortex Complete, Cortex Analyst, Document AI — the Snowflake AI surface is priced per call. The AI workloads that look incidental at the start of an experimentation programme become the largest line item on the bill within four quarters. Vendor AI on top of vendor data on top of vendor compute is the bill structure CFOs have been worrying about for two years; Snowflake's version of the stack is one of the cleanest examples in market.
Trend three — open formats matured. Apache Iceberg shipped a production-quality REST catalog. Delta Sharing became a workable cross-tenant standard. DuckDB, ClickHouse, and Trino on Kubernetes became production-grade engines a competent platform team can operate. The "modern data stack" alternative to Snowflake is not a 2024 thought experiment any more. It is something teams in the Middle East are running in production.
The combination is the migration crisis: the consumption bill is compounding, the AI premium is accelerating it, and the technical alternatives have matured into options a platform team can actually adopt.
A working architecture for portable analytics
The pattern that works:
Storage — open formats on object storage. Iceberg or Delta on AWS S3, Azure Blob, or GCP GCS. The data is written by your ingestion pipelines in the open format and read by any engine. The data is portable across providers and queryable from multiple engines without copying.
Catalogue — open REST catalog. Iceberg REST or Unity Catalog (open variant) sit between the storage and the engines. The catalogue owns the table definitions, the schema versions, and the access policies. Multiple engines query the same tables against the same catalogue without conflict.
Engines — fit-for-purpose. Trino or StarRocks for ad-hoc SQL across large tables. DuckDB inside applications for small to medium analytical queries with the lowest possible latency. ClickHouse for high-cardinality OLAP. Apache Spark on Kubernetes for the ML and large-batch workloads. Each engine reads the same Iceberg tables; the engine is selected per workload.
Semantic layer — open. Cube, dbt semantic layer, or Malloy define metrics once and serve every BI tool against the same definitions. The semantic layer is portable; the BI tool is replaceable; the metric definitions are not coupled to a vendor.
AI layer — your model, your data. LLMs run against the same Iceberg tables for text-to-SQL, document extraction, and agentic workflows. The model is selected and swapped on your timeline. The cost is per token at the model layer, not per call at the warehouse layer.
This stack is operationally heavier than Snowflake in raw human cost. It is also dramatically cheaper to run at the scale a Middle East enterprise typically operates, and the cost curve flattens with workload rather than compounding.
How to start from where you are
The migration from Snowflake to an open stack is not a big-bang project. It is a phased move that runs in parallel for an extended period. The pattern we recommend:
Phase one — write twice. Every new table that enters the warehouse is written to both Snowflake (where the existing queries continue) and to Iceberg on object storage (where the new stack will run). The two stay in sync. This phase is low-risk; nothing changes for end users.
Phase two — read from open. New analytical workloads — new dashboards, new ML pipelines, new ad-hoc queries — read from the Iceberg surface. Old workloads continue against Snowflake. The team builds operational competence on the open stack without disturbing existing reports.
Phase three — migrate the heavy queries. The Snowflake queries with the highest credit consumption are identified and moved to Trino or ClickHouse against the same data. This is where the consumption bill starts to bend. The migration is per-query, not per-table, and is fully reversible.
Phase four — retire the warehouse surface. The Snowflake surface area shrinks as queries migrate. The renewal at the end of the cycle reflects the reduced footprint. The migration completes when the only remaining Snowflake workloads are the ones where Snowflake is genuinely the right engine — typically a small set of workloads that justify staying on the consumption meter.
Phase one to phase three typically takes two quarters for a Middle East enterprise running a mid-sized Snowflake estate. Phase four runs at the renewal cycle.
The AI workload conversation
The Cortex AI migration is the conversation that becomes urgent fastest. Every per-call AI workload on Cortex Complete is a workload that can run on a model the organisation has selected, against the same Iceberg tables, on infrastructure the platform team operates. The migration is not technically demanding; the demand is on the team's familiarity with operating model inference at scale.
We have run this migration end-to-end for clients in the Middle East data and analytics sector. The shape: a small platform team takes over the AI workload at handover, the model selection is decoupled from the warehouse, the per-call cost disappears, and the AI roadmap accelerates because the team is no longer waiting for Snowflake to ship a Cortex feature.
The saasinator perspective
We are not arguing that Snowflake is the wrong platform for every workload. The platform is excellent for specific use cases — ad-hoc analytics across very large tables with unpredictable concurrency, cross-tenant data sharing under regulatory constraints, organisations where the platform team is small and the data engineering competence is limited. For those use cases, Snowflake is a defensible choice on a per-workload basis.
We are arguing that the default of "Snowflake for everything" stops being rational when the AI workloads enter the picture, when the team has the competence to operate an open stack, and when the consumption bill has compounded to the point where the per-workload analysis would never have approved the current footprint if it were a green-field decision.
Portability is a strategy. The strategy starts with an architecture, runs through a phased migration, and ends with a per-workload decision on which workloads stay on a vendor consumption meter and which workloads move to owned infrastructure.
What we would tell a Middle East data engineering leader
The migration is doable. The architecture is documented. The team competence is the gating factor. Start the dual-write today and have the option ready at the next renewal — even if you do not exercise it. Optionality on the renewal is leverage on the renewal.
Book a diagnostic. Bring six months of Snowflake credit consumption, the top ten workloads by cost, and the AI workloads currently on Cortex. Ten working days. We tell you which workloads to dual-write today and what the migration would look like for the rest.