Anatomy of a Cloud Data Platform

Same three layers, three vocabularies

Snowflake, Databricks and BigQuery look wildly different in their docs, but under the marketing they share the same three-layer anatomy. Learn the layers once and every vendor's jargon becomes translation, not new learning:

• Storage layer — Where bytes durably live, in open or proprietary columnar format on object storage. Snowflake: proprietary micro-partitions in its managed storage. Databricks: Delta Lake (Parquet + a transaction log) in your lake. BigQuery: the Capacitor columnar format in Google-managed Colossus storage.
• Compute layer — The engines that scan storage. Snowflake: virtual warehouses (T-shirt-sized clusters). Databricks: clusters / SQL warehouses running Spark + the Photon engine. BigQuery: slots (serverless units of CPU drawn from a shared or reserved pool).
• Services / metadata layer — The brain: query optimiser, security & RBAC, transactions, the catalogue. Snowflake: the Cloud Services layer. Databricks: the control plane + Unity Catalog. BigQuery: the Dremel engine + IAM + the BigQuery metadata service.

Use Case Example: 'Grant analysts read on the sales table' is the services layer everywhere — only the syntax differs (GRANT SELECT vs Unity Catalog grants vs IAM roles). 'Make this query faster' is the compute layer — resize the warehouse, scale the cluster, or buy more slots. Knowing which layer a problem lives in tells you which knob to turn on any of the three platforms.

A cloud data platform is a restaurant. The storage layer is the walk-in fridge — ingredients kept cold and safe. The compute layer is the line cooks — add cooks for the dinner rush, send them home when it's quiet. The services layer is the head chef + front-of-house — taking orders, deciding who's allowed in the kitchen, and routing each ticket efficiently. A slow kitchen on a busy night is a cooks problem (compute), not a fridge problem (storage) — and that's true whether the sign outside says Snowflake, Databricks or BigQuery.

The shared three-layer anatomy, with each vendor's word

Read each row as one concept in three dialects.

Vocabulary field guide: same ideas, vendor words

When teams say these platforms are confusing, they often mean the same concept has three names. Use this table as your translator:

Vocabulary trap to avoid: do not compare 'warehouse' literally. In Snowflake, a warehouse is compute only. In generic data architecture, a data warehouse is the whole analytical system. A Snowflake virtual warehouse is closer to a Databricks SQL warehouse or a BigQuery slot reservation than to the database itself.

Most-used production examples

These are the patterns you will see repeatedly in real companies. The vendor changes; the pattern survives.

Rule of thumb: if the workload is mostly SQL dashboards and finance reports, start your mental model with Snowflake or BigQuery. If the workload mixes engineering, streaming, notebooks and ML over open files, start with Databricks. Then check cloud, skills, governance and cost.