Stop Comparing Teradata, Snowflake, and Databricks. Start Asking These Questions Instead.

A vendor-neutral look at the architectural trade-offs that actually matter

I have spent over 20 years building and optimising enterprise data warehouses, mostly on Teradata, and increasingly on Snowflake and Databricks. What I have observed repeatedly is that platform selection decisions are driven by slide decks, analyst quadrants, and licensing pressure — not by the architectural questions that determine whether the platform will actually work for a given organisation.

This article is not a feature comparison. It is a list of questions I would ask if I were the person who has to sign the purchase order — and live with the consequences for the next five to ten years.

---

The storage-compute separation: do you actually benefit?

Both Snowflake and Databricks are built on a fundamental architectural principle that Teradata does not share: the separation of storage and compute. Data lives as files on cloud object storage (S3, ADLS, GCS), and compute resources spin up independently, read what they need, and shut down. You pay for each independently, and each scales independently.

This sounds compelling in every vendor presentation. The question I would ask first is brutally simple: what does my workload profile actually look like?

If the organisation runs a steady, predictable analytical workload eighteen hours a day — which is typical in banking, insurance, and telecom — the storage-compute separation buys less than the slide deck suggests. You are paying for compute that is already running. Elasticity does have value for intra-day peaks — scaling from four nodes to sixteen during the month-end close, then back to four — but even that value depends on how pronounced and frequent those peaks actually are. Most enterprises I have worked with dramatically overestimate their peak-to-trough ratio.

The follow-up question is equally important: What is my actual data gravity? If 80% of queries hit the same 20% of tables — which is common in a properly designed data warehouse — then the separated storage model forces repeated movement of that hot data across the network into a local cache. In Teradata, data resides permanently on the AMP — there is no network hop between the storage and compute tiers, though redistribution between AMPs during query execution incurs a separate cost that exists in all distributed systems. The question is not whether caching solves the storage-compute gap, but whether the overhead of constantly re-warming caches is worth the flexibility gained.

---

The cold cache problem: a cost nobody puts on the slide

Both Snowflake and Databricks rely on local SSD caching to bridge the latency gap between their compute nodes and the remote object storage where data permanently resides. The mechanism is conceptually similar: when a query fetches data from remote storage, that data is cached locally on NVMe SSDs so subsequent queries avoid the network round-trip.

There is a critical difference between the two implementations. Snowflake caches data in its original columnar micro-partition format. Databricks Photon transcodes the data into a different columnar format optimised for SIMD vectorised processing. The Databricks cache is not just the same data stored closer to the CPU — it is the data reorganised for how the Photon engine consumes it.

In both cases, the cache is volatile. Suspend a Snowflake virtual warehouse, and the cache is gone. Terminate a Databricks cluster, and the cache is gone. This creates a question that belongs in every TCO analysis but rarely appears there: what is the cost of a cold start, measured in business terms?

If the morning reporting window opens at 06:00 and the warehouse was suspended overnight, how long will it take for dashboards to respond at an acceptable speed? What does it cost to keep the warehouse running all night just to keep the cache warm? For Databricks specifically, how much of the Photon transcoding overhead is paid on every cold start? In fairness, modern partition pruning on both platforms means the cold-cache penalty applies only to the working set, not the entire dataset — but even a pruned working set of several hundred gigabytes still takes meaningful time to re-cache over a network.

To be fair, Databricks offers mitigations: cluster pools pre-allocate instances so the virtual machines are already running when a job starts, and serverless compute shifts lifecycle management to Databricks itself. These reduce the time to cold start, but they do not eliminate the underlying constraint — the cache is still cold, and the data still needs to be fetched and transcoded before queries run at full speed.

These are real operational costs. They never appear in the vendor TCO calculation. To be precise, Teradata also has a caching hierarchy — the FSG cache bridges the gap between RAM and local disk, just as the cloud platforms bridge the gap between SSD and object storage. The difference is the size of the latency gap being bridged. RAM to local disk is microseconds. SSD to object storage over a network is in the milliseconds range. That is orders of magnitude, and it is why a cold start on Teradata is a non-event while a cold start on a cloud platform is an operational concern.

---

Photon and the hybrid execution model: how much of your workload actually benefits?

Databricks built the Photon engine to address a fundamental limitation: Apache Spark runs on the JVM, which introduces garbage collection pauses, object creation overhead, and an inability to exploit modern CPU features such as SIMD vectorisation. Photon is written from scratch in C++ and processes data in columnar batches rather than row by row.

The performance improvement is real. Databricks reports two to eight times speedup on analytical workloads, and the architectural reasoning is sound — native code with explicit memory management will always outperform a garbage-collected runtime for this class of work. This is, incidentally, the same conclusion that traditional data warehouse engines like Teradata arrived at years ago: native code, direct hardware access, no garbage collector in the execution path. The difference is that Photon has to solve a harder deployment problem — running on heterogeneous commodity cloud hardware with elastic scaling and open data formats, rather than on a fixed, purpose-built appliance.

However, there is an architectural constraint that deserves close scrutiny. Photon does not replace Spark — it runs alongside it. The query optimiser routes each physical operator to either Photon or the standard Spark engine, depending on whether Photon supports it. If a query calls a Python or Scala UDF, uses the RDD API, or hits an unsupported operation, execution falls back to the JVM for the remainder of the workload.

The question I would ask is: what percentage of my current workload uses functionality that Photon does not support? If the ETL pipelines are full of custom transformations — and in my experience, most enterprise pipelines are — then the Photon performance numbers are irrelevant for those workloads. You are buying a sports car that can only be driven on certain roads.

It is worth noting that Databricks has improved this situation. Python UDFs now use Apache Arrow serialisation for the handoff between Photon and the JVM, which significantly reduces the serialisation penalty compared to earlier versions. The gap is narrowing. But the core architectural point remains: native SQL on Photon will always outperform UDF-heavy workloads, and organisations should audit their pipeline complexity before assuming Photon benchmarks apply to their reality.

The follow-up: What is the roadmap for closing the Photon coverage gap? If Databricks plans to support UDFs natively within two years, that changes the calculus. If not, the organisation must plan for a permanent two-tier performance reality within the same platform.

---

Result caching: an underappreciated differentiator

Snowflake offers a result cache at the cloud services layer that stores the output of every query for twenty-four hours. If the same query is resubmitted and the underlying data has not changed, the result is returned instantly — no warehouse required, no compute cost incurred.

In a BI-heavy environment where the same dashboards get refreshed by dozens of users throughout the day, this is architecturally significant. The query runs once, and everyone else gets the answer for free.

Databricks does not have an equivalent mechanism at the platform level. It offers Delta Cache for data caching and DataFrame persistence in memory, but neither provides the zero-compute-cost instant return of an identical query that Snowflake’s result cache delivers. Photon accelerates the execution of each query, but each query still executes.

Teradata handles this differently again. There is no built-in result cache in the Snowflake sense, but the combination of FSG cache (which keeps recently accessed data blocks in RAM on each AMP) and the lack of network latency to storage means that repeated queries against the same data are already fast by design.

The question for any BI-heavy organisation evaluating all three platforms: how many of my daily queries are effectively duplicates? If the answer is “a significant percentage,” Snowflake has a structural advantage that raw engine speed cannot compensate for.

---

Teradata in this comparison: why are you actually leaving?

This is the question I would honestly ask myself before spending a single euro on migration planning.

If Teradata meets the organisation’s needs and performance is acceptable, then the architectural trade-offs of both cloud platforms — cold caches, network latency to storage, hybrid execution engines, volatile compute — are problems the organisation is choosing to adopt. The Teradata architecture does not have these problems because it never separated storage from compute in the first place.

The compelling reasons to leave are real, but they are specific: the licensing model is unsustainable, the organisation needs elasticity it genuinely cannot get, or it needs capabilities that Teradata does not offer natively. And those capabilities are not trivial — native JSON and semi-structured data querying without ETL, zero-copy data sharing with external partners, Python and ML model execution inside the compute engine, streaming ingestion as a first-class citizen, and an open storage format that prevents permanent vendor lock-in at the data layer. These are genuine architectural advantages of the cloud platforms, not marketing fluff, and for some organisations, they are the deciding factor.

To be fair to Teradata as well, this is not the same platform it was ten years ago. VantageCloud offers cloud infrastructure deployment, and ClearScape Analytics adds native ML and advanced analytics capabilities. Teradata has moved toward cloud-native features. But the core performance differentiator — data locality on the AMP, no network hop to storage — remains the architectural property that sets it apart, and that property is inherent to the coupled design, not something that can be bolted on to a decoupled system.

If the answer is primarily “licensing cost,” then the honest follow-up is whether the total cost of ownership after migration — including the migration itself, the re-engineering of ETL, the re-training of teams, and the operational costs of managing cache behaviour, cluster sizing, and performance tuning in a fundamentally different architecture — is actually lower.

---

The meta-question

If I were sitting across the table from any of these three vendors, the final question I would ask is this:

Show me a reference customer in my industry, at my scale, who migrated from Teradata and achieved the promised TCO reduction after twenty-four months in production — not a proof of concept, not a sandbox, but a full production migration including the cost of the migration itself.

In my experience, that reference is extremely difficult to produce. Not because the platforms are bad — all three are technically excellent in their respective design spaces — but because most large-scale migrations are still in progress, or have quietly exceeded their budgets.

The right platform is the one whose architectural trade-offs align with your actual workload, usage patterns, and your organisational capability to operate it. That answer is different for every organisation, and no vendor slide deck will give it to you.

---

Roland Wenzlofsky is the founder of DWHPro, a Vienna-based enterprise data warehousing consultancy. He is a Teradata Certified Master with over twenty years of experience across European banking, insurance, and telecom, and the author of “Teradata Query Performance Tuning.” DWHPro provides vendor-neutral advice across Teradata, Snowflake, and Databricks.