Snowflake published benchmark results on July 16, 2026. The company claims its run_batch() API delivered up to 6.5x higher throughput and up to 5.8x lower compute cost per million rows compared to Amazon SageMaker Batch Transform and Databricks Spark UDF. CPU configurations were standardized across all three platforms. RAM differed but Snowflake states it was not a bottleneck on the tested workloads.
This is a vendor-published benchmark. Snowflake set the test conditions, selected the workloads, and reported the results. Treat the numbers as directional, not definitive. That said, the architectural explanation is specific and testable.
What Snowflake Actually Tested
The benchmark covered two model types. The first was XGBoost at 10 billion rows. Near-zero per-row cost requires high volume to expose platform overhead, Snowflake explains. The second was a Sentence Transformer embedding model at 10 million rows. There, throughput and cost stabilized at that scale. GPU utilization determines performance when compute is the primary constraint.
These two profiles stress different parts of the stack. Results represent median values from three independent runs. Pricing used public on-demand rates for each platform. The cost calculation excluded storage, orchestration, and egress. Teams with heavy egress or orchestration overhead may see a different total.
What Drives the Gap
Snowflake attributes the performance to Ray Data operator fusion and Arrow-native processing.
Ray Data uses operator fusion to optimize execution. The approach fuses adjacent logical operators into single physical units, minimizing intermediate data materialization. Snowflake's implementation reduces the pipeline from five stages with four object-store boundaries to three streaming stages with zero full-dataset materialization barriers.
Arrow-native processing and DAG fusion limit data-movement overhead for XGBoost workloads.
For I/O-bound operations, Snowflake declares minimal CPU requirements — for example, num_cpus=0.01 — to maximize I/O concurrency across stage read and write tasks.
Execution runs entirely on Snowpark Container Services. The warehouse materializes the input DataFrame, then suspends automatically. Compute provisions, runs, and tears down without user intervention.
Snowflake describes Databricks Spark UDF as requiring managing a Spark cluster and submitting a job to it, and Amazon SageMaker Batch Transform as sending batched S3 payloads to a dedicated offline inference container via a transform job. Snowflake argues both architectures introduce boundaries its fused pipeline avoids.
For teams already on Snowflake, the immediate question is whether your scheduled inference jobs use native SQL batch functions or an external platform. Snowflake recommends its job-based API for workloads decoupled from SQL, particularly file-based and unstructured data at scale. SQL-inline predictions belong on warehouse-based batch inference functions.
Batch Inference Jobs requires snowflake-ml-python version 1.39.0 or later. The output stage must be an internal Snowflake stage. External stage support is limited to Amazon S3 with server-side encryption; Azure Blob Storage and Google Cloud Storage are not supported as external input stages. SPCS-based inference is not available in government regions.
The Decision That Changes
If your team is reviewing infrastructure contracts for inference compute in the next two quarters, this benchmark is relevant. For teams whose justification for a separate ML platform rests on Snowflake being a data warehouse rather than a compute engine, that argument may be harder to sustain. The 6.5x throughput claim is backed by published methodology that teams can replicate on their own workloads.
The most direct test is running your own XGBoost or embedding workload through run_batch() on a matched compute pool. Compare server-side execution time and compute cost against your current platform at the same row count. That tells you whether the gap holds for your data.
