Pricing models compared
Each platform ties cost to a different unit of measurement, and that choice shapes how predictable — or unpredictable — a bill can be:
- Snowflake — credits per warehouse-second. A virtual warehouse of a given size (X-Small, Small, Medium, and larger) consumes credits while running, billed per second, with auto-suspend reducing cost during idle periods. Storage is billed separately.
- BigQuery — bytes scanned (on-demand) or reserved slots (flat-rate). The default on-demand model charges per byte a query actually scans, regardless of how long the query takes to run. An optional capacity model reserves a fixed amount of query-processing slots for predictable, scan-volume-independent billing.
- Databricks — DBUs (Databricks Units) per hour. A processing-capacity unit billed on top of the underlying cloud provider's own compute and storage charges, applying to SQL warehouses as well as broader Spark workloads.
SQL syntax differences
platform-syntax-differences.sql
-- Snowflake: semi-structured (VARIANT) field access
SELECT data:customer:email AS email FROM raw_events;
-- BigQuery: nested/repeated field access (STRUCT/ARRAY)
SELECT customer.email FROM raw_events;
-- Databricks (Spark SQL): similar nested access, dot notation
SELECT customer.email FROM raw_events;
-- Core SQL — identical across all three
SELECT customer_id, COUNT(*)
FROM orders
GROUP BY customer_id;The gap widens for DDL, semi-structured data functions, and platform-specific extensions — a query relying on those isn't a drop-in copy-paste between platforms.
Which workloads fit which platform
- Snowflake tends to fit teams doing primarily SQL-based analytics who want clean separation of storage and compute without managing infrastructure.
- Databricks tends to fit teams whose workloads mix SQL analytics with machine learning or heavy Spark-based data processing in the same platform.
- BigQuery tends to fit teams already inside the Google Cloud ecosystem who want a serverless experience with minimal capacity planning.
Side-by-side comparison
| Aspect | Snowflake | Databricks | BigQuery |
|---|---|---|---|
| Billing unit | Credits / warehouse-second | DBUs / hour | Bytes scanned or reserved slots |
| Compute model | Sized virtual warehouses | Clusters / SQL warehouses | Serverless |
| Strongest fit | SQL-first analytics | SQL + ML/Spark together | Serverless, GCP-native teams |
| Semi-structured data | VARIANT type | Struct/array (Spark SQL) | Struct/array (nested/repeated fields) |
Common mistakes
- Comparing prices without accounting for workload shape — a bytes-scanned model can be cheaper for infrequent large queries and more expensive for frequent small ones, or vice versa for other billing models.
- Assuming SQL is fully portable between platforms untested, then discovering platform-specific functions block a lift-and-shift migration.
- Leaving Snowflake warehouses running without auto-suspend, paying for idle compute unnecessarily.
- Not setting BigQuery on-demand query cost controls, allowing an unexpectedly expensive full-table scan to run unchecked.
Key takeaways
- Each platform bills on a fundamentally different unit — warehouse-seconds, DBUs, or bytes scanned — so cost comparisons need to account for actual workload shape.
- Core SQL is largely consistent across all three; semi-structured data syntax and platform extensions are not.
- Workload mix (pure SQL analytics vs SQL + ML/Spark vs serverless simplicity) is a better selection criterion than price alone.
- Cost controls (auto-suspend, query cost limits, slot reservations) matter as much as the pricing model itself.