Real-Time Analytics on Snowflake: A Repeatable Benchmark for Sub-Second Latency at ScaleSnowflake 实时分析：实现大规模亚秒级延迟的可重复基准测试
The views expressed here are mine alone and do not necessarily reflect the views of my current, former, or future employers.此处表达的观点仅代表我个人，并不一定反映我当前、过去或未来雇主的观点。
We are now in an agentic era with a combination of engines to try to serve queries for real-time needs. To serve the various users, enterprises end up stitching together ETL pipelines, CDC streams, and/or caching layers. Real-time engines, such as ClickHouse, require their own security model and a copy of your data. Iceberg eases the data-movement burden but not the entitlement problem. This is very reminiscent of the 2015 days of Hadoop and Data Warehouses competing for a single copy of data.我们现在处于代理（Agentic）时代，需要结合各种引擎来尝试满足实时查询需求。为了服务各类用户，企业最终不得不拼凑 ETL 流水线、CDC 数据流和/或缓存层。诸如 ClickHouse 之类的实时引擎需要其自身的安全模型以及数据副本。Iceberg 减轻了数据移动的负担，但并未解决权限问题。这非常让人想起 2015 年 Hadoop 和数据仓库争夺单一数据副本的时代。
I wrote about closing the ingestion half of this gap in 2022 with Snowpipe Streaming — getting data into Snowflake within seconds of an event. This article is the serving half. Snowflake’s Interactive Warehouse is designed to close the gap on the query side: serving that data at sub-second latency with the governance model you already have, not a separate one to manage. The benchmark below tests exactly that.我在 2022 年撰写过关于通过 Snowpipe Streaming 弥补这一差距中摄取部分的文章——即在事件发生后的几秒钟内将数据导入 Snowflake。本文讨论的是服务部分。Snowflake 的交互式仓库（Interactive Warehouse）旨在弥补查询端的差距：利用您现有的治理模型，以亚秒级延迟提供数据，而无需管理独立的模型。下文的基准测试正是对此进行的验证。
Databricks also claims their Lakehouse RT product with the Reyden engine solves this problem. Unfortunately, their product is still in Preview and based on a video from Aug 2026, their engine is pushing 742 rows at 620ms.Databricks 也声称其带有 Reyden 引擎的 Lakehouse RT 产品解决了这个问题。遗憾的是，他们的产品仍处于预览阶段；根据 2026 年 8 月的一段视频，其引擎在 620 毫秒内处理了 742 行数据。
In another post, Ali Ghodsi reposted a claim that the Reyden engine can query 1 billion rows in 258 milliseconds. I don’t have a way to reproduce either the 258ms or 620ms claim.在另一篇文章中，Ali Ghodsi 转发了一条声称 Reyden 引擎可以在 258 毫秒内查询 10 亿行数据的消息。我无法复现 258 毫秒或 620 毫秒的声明。
I was coincidentally working on this benchmark when I saw his post. And it’s why transparency matters when sharing numbers. Data points such as these should be repeatable and/or verifiable.我刚好在看到他那篇文章时正在进行这项基准测试。这就是为什么在分享数据时透明度很重要。此类数据点应该是可重复和/或可验证的。
Let’s see how Snowflake’s Interactive Warehouse performs using repeatable steps and code. Full GitHub code is available here:让我们看看 Snowflake 的交互式仓库如何通过可重复的步骤和代码进行性能表现。完整的 GitHub 代码可在此处获取：
The need for Interactive Queries交互式查询的需求
Real-time dashboards, data-powered APIs, and AI agents share the same requirement: many people (or agents) asking similar questions at the same time and expecting sub-second answers. That’s a different problem than a nightly ETL job or an analyst running an ad-hoc query. It’s not about how much data and compute you can throw at it; it’s about how many of those queries you can serve simultaneously as quickly as possible.实时仪表板、数据驱动型 API 和 AI 代理有着共同的要求：许多人（或代理）同时提出类似的问题，并期望在亚秒级时间内得到答案。这与每晚运行的 ETL 作业或分析师运行的即席查询是不同的问题。这不在于你能投入多少数据和计算资源，而在于你能以多快的速度同时处理多少此类查询。
Historically, this required standing up a separate serving layer. That’s real operational overhead for business users and agents. Snowflake’s Interactive Warehouses are built to close that gap without the extra infrastructure, delivering sub-second, predictable latency at high concurrency, on data you already have.从历史上看，这需要建立一个独立的服务层。这对业务用户和代理来说是巨大的运营开销。Snowflake 的交互式仓库旨在在无需额外基础设施的情况下弥补这一差距，在您既有数据的基础上，以高并发实现亚秒级、可预测的延迟。
This isn’t about running more queries in parallel; it’s about how fast each query finishes. Interactive Warehouses keep your tables warmed in a local cache and run them through a query engine tuned for short, selective queries, so each query completes faster. This lets concurrency slots free up and refill more often per second, showing up as higher realized QPS at the same connection count.这并非关于并行运行更多查询，而是关于每个查询完成的速度。交互式仓库将您的表保留在本地缓存中，并使其通过针对短时、选择性查询进行优化的查询引擎运行，从而使每个查询完成得更快。这使得并发槽位能够更频繁地释放和填充，在相同的连接数下表现为更高的实际 QPS。
Let’s Dive into the Reproducible Benchmark深入了解可复现的基准测试
As mentioned above, the code is available in my GitHub repository. My aim was to mimic the high-concurrency nature of a true analytics production workload, pushing the interactive warehouse using various table types and patterns. Here is what was tested.如上所述，代码可在我的 GitHub 仓库中找到。我的目标是模拟真实分析生产工作负载的高并发特性，利用各种表类型和模式来推动交互式仓库。以下是测试内容。
- Snowflake Native TableSnowflake 原生表
- Snowflake Interactive TableSnowflake 交互式表
- External Iceberg Table外部 Iceberg 表
- Snowflake Interactive Table with Masking Policy带有掩码策略的 Snowflake 交互式表
For each table I ran two different queries: a point lookup (PL), returning a single row, and an aggregate mimicking a Customer 360 (Agg) query. Note that the masking policy query test was not run with aggregation, only point lookup. Both queries are run at concurrency levels from 10 to 1000 concurrent connections. The script uses a closed-loop model where each parallel connection fires the next query the instant the previous one returns.对于每张表，我运行了两种不同的查询：一种是返回单行的点查询（PL），另一种是模拟客户 360 视图的聚合查询（Agg）。请注意，掩码策略查询测试未进行聚合测试，仅进行了点查询。两种查询均在 10 到 1000 个并发连接的级别下运行。脚本使用闭环模型，每个并行连接在前一个查询返回的瞬间触发下一个查询。
-- =====================================================================
-- Real-Time Analytics on Snowflake — Benchmark Query Reference
-- Query patterns tested against TXN_HISTORY_IT (1B rows, 100M customers)
-- =====================================================================
-- ---------------------------------------------------------------------
-- 1. POINT LOOKUP
-- Returns exactly 1 row: No GROUP BY.
-- ---------------------------------------------------------------------
SELECT
COUNT(*),
SUM(UNIT_PRICE * QUANTITY)
FROM SNOW_DB.SNOW_SCHEMA.TXN_HISTORY_IT
WHERE CUSTOMER_ID = %s; -- bind parameter, not a literal value
-- ---------------------------------------------------------------------
-- 2. CUSTOMER 360 (AGGREGATION)
-- Same filter as Point Lookup, but breaks the same customer's
-- transactions with GROUP BY. Returns ~10 rows on average.
-- ---------------------------------------------------------------------
SELECT
PRODUCT_CATEGORY,
STORE_ID,
COUNT(*),
SUM(UNIT_PRICE * QUANTITY) AS SPEND,
MIN(TXN_DATE) AS FIRST_PURCHASE,
MAX(TXN_DATE) AS LAST_PURCHASE
FROM SNOW_DB.SNOW_SCHEMA.TXN_HISTORY_IT
WHERE CUSTOMER_ID = %s
GROUP BY 1, 2
ORDER BY 4 DESC;
-- ---------------------------------------------------------------------
-- 3. POINT LOOKUP (EMAIL) — masking policy test
-- Identical shape to the Point Lookup query, but also selects
-- CUSTOMER_EMAIL (masked column).
-- ---------------------------------------------------------------------
SELECT
ANY_VALUE(CUSTOMER_EMAIL), --masked column
COUNT(*),
SUM(UNIT_PRICE * QUANTITY)
FROM SNOW_DB.SNOW_SCHEMA.TXN_HISTORY_IT
WHERE CUSTOMER_ID = %s;
-- Note: every %s above is a bind parameter (randomized CUSTOMER_ID per call)
-- This lets Snowflake reuse cached query plan across every execution
-- see "Parameterize your queries" in Best Practices.Note: I tested up to 1,000 concurrent connections because past that point the client became the bottleneck, not Snowflake. Generating 1,000+ truly concurrent queries from a single machine strained Python across multiple processes. 1,000 was enough to show the trend: linear scaling and a second cluster supporting additional demand after 250.注意：我测试了高达 1,000 个并发连接，因为超过该点后，瓶颈变成了客户端而非 Snowflake。从单台机器生成 1,000 多个真正的并发查询给 Python 的多进程带来了压力。1,000 个连接足以展示趋势：线性扩展，并在 250 个连接后通过第二个集群支持额外需求。
The numbers below were generated using Interactive Warehouse of size XS for Concurrency levels of 10 to 250. Past a concurrency of 250, slowdowns started to show at the higher end (p90), which meant the warehouse was starting to queue queries. Snowflake is able to scale both vertically and horizontally. Moving to a Small warehouse with two clusters was best able to handle the higher throughput and enable linear scaling.下方的数字是使用 XS 尺寸的交互式仓库，在 10 到 250 个并发级别下生成的。当并发超过 250 时，高端（p90）开始出现减速，这意味着仓库开始对查询进行排队。Snowflake 能够进行垂直和水平扩展。改用具有两个集群的 Small 仓库最能处理更高的吞吐量并实现线性扩展。
And to demonstrate the true “one-platform” nature of this workload, I benchmarked various combinations of tables: Snowflake Native and External Iceberg. The GA of both those table types is now available — you can read more about interactive warehouses here:为了展示该工作负载真正的“单一平台”特性，我对各种表组合进行了基准测试：Snowflake 原生表和外部 Iceberg 表。这两种表类型现已全面上市（GA）——您可以点击此处阅读有关交互式仓库的更多信息：
What this means for you: No need to copy or move data for similar results. For each table type, I will compare against the Interactive Table Baseline.这对您意味着什么：无需复制或移动数据即可获得类似结果。对于每种表类型，我将与交互式表基准进行比较。
Interactive Warehouse vs Regular Warehouse交互式仓库与常规仓库的对比
Having established the need for Interactive Warehouses, the first comparison puts it to the test to establish a baseline. The same table and queries, run on an Interactive Warehouse versus a regular (non-interactive) warehouse, across 10 to 1,000 concurrent connections.确定了对交互式仓库的需求后，首次比较将其投入测试以建立基准。在 10 到 1,000 个并发连接下，对交互式仓库和常规（非交互式）仓库运行相同的表和查询。
Note: QPS is defined as queries per 60-second window, measured server-side from ACCOUNT_USAGE (COUNT(status=’SUCCESS’)/60) — not client-observed, and not counting timeouts or errors.注意：QPS 定义为 60 秒窗口内的查询数，从 ACCOUNT_USAGE 服务端测量（COUNT(status='SUCCESS')/60）——而非客户端观察，且不计入超时或错误。
Note 2: Across all 2.36 million queries in this benchmark — every table type, query pattern, and concurrent level — the error rate was 0%. There were no failures, and no queries hit the Interactive Warehouse’s 5-second timeout.注意 2：在此基准测试的 236 万次查询中——涵盖所有表类型、查询模式和并发级别——错误率为 0%。没有发生失败，也没有查询达到交互式仓库的 5 秒超时限制。
As concurrency hits 250, just like standard warehouses, you can add more compute clusters and continue to see the linear scaling. In this example for point lookup queries, the run peaked at over 2,300 QPS using a Small Warehouse with two clusters. Both queries scaled to Multi-Cluster at the 500 connection mark to continue linear scaling. In both cases, Snowflake was able to handle the concurrent demand.当并发达到 250 时，就像标准仓库一样，您可以添加更多的计算集群并继续看到线性扩展。在此点查询示例中，使用具有两个集群的 Small 仓库，运行峰值超过了 2,300 QPS。两种查询均在 500 连接标记处扩展至多集群，以继续实现线性扩展。在这两种情况下，Snowflake 都能处理并发需求。
There is also a high correlation between queries per second and latency. The shorter the duration of the query, the more queries Snowflake can process in a minute. The thing that stands out with Interactive queries is that the p90 (less than 90%) of the queries returned in < 100ms. Even when a regular warehouse is fast (sub-second), it’s unable to keep up when the volume of queries increases. With interactive, the p90 stays relatively flat.每秒查询数与延迟之间也存在高度相关性。查询持续时间越短，Snowflake 在一分钟内能处理的查询就越多。交互式查询的突出之处在于，p90（低于 90%）的查询返回时间在 < 100ms。即使常规仓库速度很快（亚秒级），当查询量增加时，它也无法跟上。使用交互式仓库，p90 保持相对平稳。
Interactive Tables vs Snowflake Native交互式表与 Snowflake 原生表的对比
The Interactive Warehouse comparison showed the warehouse matters. The next question is whether the table format matters too — does a standard Snowflake table, with no migration or materialization, perform as well as a purpose-built Interactive Table on the same Interactive Warehouse?交互式仓库的比较表明仓库很重要。下一个问题是表格式是否也重要——在同一个交互式仓库上，无需迁移或物化的标准 Snowflake 表，性能是否与专门构建的交互式表一样好？
At 1,000 concurrent connections, Snowflake Native served 2,277 QPS versus the Interactive Table’s 2,349 QPS, a slight 3% delta on throughput. A standard table, no data movement, matched a purpose-built Interactive Table. This feature just went GA at the time of the blog writing and the results show.在 1,000 个并发连接下，Snowflake 原生表处理了 2,277 QPS，而交互式表为 2,349 QPS，吞吐量仅有 3% 的微小差异。标准表在无需数据移动的情况下，与专门构建的交互式表表现相当。该功能在撰写本文时刚刚全面上市，结果说明了一切。
The latency was the interesting trend for the p90 customer 360 aggregation query. Even with the p90 hovering around 300ms for this query at 250 concurrency, the two table types’ QPS stayed within 19% of each other on this query, the widest gap in the test. Again, this shows the warehouse starting to queue around this point with the larger aggregation query. Not shown is the ~200ms of queuing taking place for this query on Native Snowflake tables. There’s also a slight queuing at the 250 level for the other queries, which leads to the increased p90 latency. This is exactly why I scaled up and out at c=500. Fitting your cluster to your demand is key.对于 p90 客户 360 聚合查询，延迟趋势很有趣。即使在此查询的 250 并发下 p90 徘徊在 300ms 左右，两种表类型的 QPS 在此查询上仍保持在 19% 的差距内，这是测试中最大的差距。同样，这表明仓库在此时开始对较大的聚合查询进行排队。图中未显示的是，在原生 Snowflake 表上，此查询发生了约 200ms 的排队。其他查询在 250 级别也有轻微排队，导致 p90 延迟增加。这正是为什么我在 c=500 时进行了向上和向外扩展的原因。根据需求调整集群是关键。
Interactive Table vs External Iceberg交互式表与外部 Iceberg 表的对比
The previous tests all used Snowflake-managed tables. The next question is whether Snowflake can serve the same interactive workload directly on data it doesn’t own or manage — an externally written, catalog-linked Iceberg table without copying it to Snowflake.之前的测试均使用 Snowflake 管理的表。下一个问题是 Snowflake 是否可以直接在它不拥有或管理的数据上提供相同的交互式工作负载——即在不复制到 Snowflake 的情况下，查询外部编写、目录关联的 Iceberg 表。
For this test, I used a catalog-linked Iceberg table to simulate an external engine writing (e.g., Spark) data to an external catalog (e.g., Glue Catalog) where Snowflake is the reader. It’s a harder test because the Iceberg table reads off remote object storage through an external catalog. I demonstrated this to show how Snowflake can be used as a single serving engine without copying data.在此测试中，我使用了一个目录关联的 Iceberg 表，以模拟外部引擎（如 Spark）将数据写入外部目录（如 Glue Catalog），而 Snowflake 作为读取者。这是一个更难的测试，因为 Iceberg 表通过外部目录读取远程对象存储。我演示这一点是为了展示 Snowflake 如何在不复制数据的情况下用作单一服务引擎。
At 1,000 concurrent connections, the Iceberg table held 2,102 QPS versus the Interactive Table’s 2,349 — ~11% lower. There is a slight tradeoff with this approach but it reduces your need to move data if your SLAs can support the slightly lower throughput.在 1,000 个并发连接下，Iceberg 表保持了 2,102 QPS，而交互式表为 2,349 QPS——低约 11%。这种方法存在轻微的权衡，但如果您的 SLA 可以支持稍低的吞吐量，它减少了您移动数据的需求。
Iceberg also shows a similar trend where the latency was spiky with the p90 customer 360 aggregation query. The point lookup query held its own with a ~200ms response time in all concurrency tests. The additional data rows and aggregation spiked to over 700ms for customer 360 query — this tells me a larger cluster may have benefited for this concurrency level with Iceberg.Iceberg 也显示出类似的趋势，即 p90 客户 360 聚合查询的延迟出现峰值。点查询在所有并发测试中均保持了约 200ms 的响应时间。额外的数据行和聚合使客户 360 查询的延迟激增至 700ms 以上——这告诉我，对于此并发级别，更大的集群可能对 Iceberg 更有利。
Interactive Table vs Interactive Table with Masking Policy交互式表与带有掩码策略的交互式表的对比
The remaining question is whether governance gets in the way of any of this. Does applying a masking policy to a column add meaningful latency to an otherwise sub-second query?剩下的问题是治理是否会阻碍这一切。对列应用掩码策略是否会给原本亚秒级的查询增加明显的延迟？
I wanted to highlight using existing governance policies with interactive tables — this may not be a common use case, and honestly, I didn’t know what to expect. Running the point lookup query, I projected another column, email, where the policy displayed ***@email using a regex.我想强调在交互式表中使用现有的治理策略——这可能不是常见的用例，老实说，我不知道会发生什么。在运行点查询时，我投影了另一列 email，策略使用正则表达式将显示为 ***@email。
CASE WHEN CURRENT_ROLE() IN (‘SECURITYADMIN’, ‘ACCOUNTADMIN’) THEN val
ELSE REGEXP_REPLACE(val, '^[^@]+', '***') ENDThroughout the concurrency tests, there was only a small difference in throughput with the masked query.在整个并发测试中，掩码查询的吞吐量差异很小。
The surprising part to me was that the execution time was still sub 250ms, even when having to mask data over 143,000 times in a minute. Not shown in the chart, but I broke out the compilation and execution times to better understand the why behind the higher p90 times. The masked query has an additional 40–110ms of compilation time — this is the reason for the higher latency, not the extra column itself.令我惊讶的是，即使在一分钟内需要对数据进行 143,000 多次掩码处理，执行时间仍低于 250ms。图中未显示，但我拆分了编译和执行时间，以更好地理解 p90 时间较高的原因。掩码查询有额外的 40–110ms 编译时间——这就是延迟较高的原因，而不是额外列本身。
Further Details更多详情
For the builders, if you haven’t reviewed the GitHub, the Snowflake Setup Script is a great place to start. It has the queries to reproduce the data set and the interactive warehouse used to start kicking the tires.对于开发者，如果您还没有查看 GitHub，Snowflake 设置脚本是一个很好的起点。它包含用于复现数据集的查询以及用于开始试用的交互式仓库。
For the data folks, the details behind these numbers are listed in this public Google Sheet.对于数据人员，这些数字背后的详细信息列在此公开的 Google 表格中。
Please reach out with any questions about the data or testing methodology.如有关于数据或测试方法的任何问题，请随时联系。
Best Practices最佳实践
Warm your warehouse预热您的仓库
Your production, your user demand may be spiky but you will have known peaks (market open, start of shift, a marketing push) and troughs (weekends, evenings). Use Snowflake Tasks to scale your Interactive Warehouse’s cluster count up ahead of a known spike, then back down after.您的生产环境和用户需求可能会有波动，但您会知道高峰（市场开盘、轮班开始、营销推广）和低谷（周末、晚上）。使用 Snowflake 任务（Tasks）在已知高峰前调大交互式仓库的集群数量，之后再调小。
I didn’t test from cold for this benchmark. A warming pass ran first to get the warehouse into cache, then I measured the results. This simulated a live production workload, not a cold start. In addition, Snowflake supports adding tables to your warehouse so the cache pre-warms when the warehouse starts. This works for standard, Iceberg, dynamic, or interactive tables — get them added at least 10 min before the demand hits.我在此基准测试中没有从冷启动开始。首先运行预热以将仓库载入缓存，然后我测量了结果。这模拟了实时的生产工作负载，而非冷启动。此外，Snowflake 支持将表添加到您的仓库，以便在仓库启动时预热缓存。这适用于标准表、Iceberg 表、动态表或交互式表——请在需求到来前至少提前 10 分钟添加它们。
Wall-clock vs. server-side latency挂钟时间与服务端延迟
The numbers in this benchmark use server-side, pulled from ACCOUNT_USAGE. That’s what Snowflake measured, not what your clients or agents will actually register. Wall-clock is as important, if not more important than the server-side. 50ms on Snowflake + 500ms of network latency = ½ second.此基准测试中的数字使用服务端数据，从 ACCOUNT_USAGE 中提取。这是 Snowflake 测量到的，而不是您的客户端或代理实际记录的。挂钟时间与服务端时间一样重要，甚至更重要。Snowflake 上的 50ms + 500ms 网络延迟 = 0.5 秒。
This benchmark didn’t take it into account because of the variability of where your client sits (on-prem vs cloud), your driver, connection pooling, and proxy settings. Within the code base, it includes wall-clock metrics so you can view them in addition to the server side metrics. With my setup (on-prem MacBook Pro) I saw an additional ~150–175ms client/network overhead — you can use the tool to see how the numbers break down and where latency is stacking up.由于您的客户端所处位置（本地与云端）、驱动程序、连接池和代理设置的可变性，此基准测试未将其计入。在代码库中，它包含了挂钟时间指标，以便您可以在服务端指标之外查看它们。在我的设置（本地 MacBook Pro）中，我看到了额外的约 150–175ms 客户端/网络开销——您可以使用该工具查看数字是如何分解的以及延迟堆积在何处。
Concurrency并发性
I ran a closed-loop client — 16 Python processes, each having its own connection pool, firing the next query as soon as the last one returned.我运行了一个闭环客户端——16 个 Python 进程，每个进程都有自己的连接池，在前一个查询返回后立即触发下一个查询。
On the warehouse side I set MAX_CONCURRENCY_LEVEL (MCL) to 32, up from the default of 8. On its own, MCL=32 didn’t move QPS much. What that bought was headroom — when a flood of queries hits at once, a higher MCL starts more of them immediately instead of queuing them. That headroom matters more once you’re running Multi-Cluster. Set MCL based on how your traffic actually is, whether or not you’re using MCW. You will want to test all these numbers (processes, MCL, MCW) for your workload.在仓库端，我将 MAX_CONCURRENCY_LEVEL (MCL) 从默认的 8 设置为 32。MCL=32 本身并没有显著提升 QPS。它带来的是余量——当大量查询同时涌入时，更高的 MCL 会立即启动更多查询，而不是将它们排队。一旦您运行多集群，这种余量就更重要了。根据您的实际流量设置 MCL，无论您是否使用 MCW。您需要为您的工作负载测试所有这些数字（进程、MCL、MCW）。
You can push past c=1000 — just make sure your client can actually generate the demand. At high concurrency the load generator can become the bottleneck before the warehouse does, so scale your process/thread count with your core count before trusting the numbers.您可以突破 c=1000——只需确保您的客户端确实能产生该需求。在高并发下，负载生成器可能会在仓库之前成为瓶颈，因此在信任这些数字之前，请根据您的核心数扩展进程/线程数。
Query Patterns查询模式
Test your queries before you begin testing Interactive Warehouses. Clustering by CUSTOMER_ID is what made the regular-warehouse point lookups fast, and the same clustering carried over to Interactive too. Getting your clustering key (or search optimization) right for your access pattern matters more than the warehouse size behind it. Check partition pruning before testing and utilize general Snowflake query best practices. If Snowflake isn’t pruning, the warehouse size won’t fix it either.在开始测试交互式仓库之前，请先测试您的查询。按 CUSTOMER_ID 聚类使得常规仓库的点查询变快，同样的聚类也延续到了交互式仓库中。为您的访问模式选择正确的聚类键（或搜索优化）比其背后的仓库大小更重要。在测试前检查分区修剪，并利用 Snowflake 的一般查询最佳实践。如果 Snowflake 没有进行修剪，那么仓库大小也无法解决问题。
A counter-intuitive note: Fewer partitions aren’t automatically better — they often create more overlap between partitions’ min/max ranges, which hurts pruning. More micro-partitions or files can reduce that overlap and let Snowflake skip more of them per query. If testing with Iceberg, consider targeting a file size of 16MB (rather than default of 128MB) so the optimizer can prune more files.一个反直觉的注意点：分区越少并不一定越好——它们通常会在分区的最小/最大范围之间产生更多重叠，这会损害修剪效果。更多的微分区或文件可以减少这种重叠，并让 Snowflake 在每次查询时跳过更多分区。如果使用 Iceberg 进行测试，请考虑将文件大小目标设定为 16MB（而非默认的 128MB），以便优化器可以修剪更多文件。
Parameterize your queries参数化您的查询
Every point lookup and aggregation in this benchmark used bind parameters (e.g., WHERE CUSTOMER_ID=?), not literal values in the SQL text. This lets Snowflake reuse a cached query plan across every call instead of recompiling for each unique value — the same mechanism behind the low compilation times you see throughout this benchmark. If you’re building a data-powered API or agent workload, parameterize your queries; hardcoding literals decreases plan caching and will show up as additional latency.此基准测试中的每个点查询和聚合都使用了绑定参数（例如 WHERE CUSTOMER_ID=?），而不是 SQL 文本中的字面值。这使得 Snowflake 可以在每次调用中重用缓存的查询计划，而不是为每个唯一值重新编译——这也是此基准测试中低编译时间背后的机制。如果您正在构建数据驱动型 API 或代理工作负载，请参数化您的查询；硬编码字面值会降低计划缓存，并表现为额外的延迟。
Conclusion结论
The repeatable benchmark results are clear. Snowflake’s Interactive Warehouse delivers production-scale sub-second latency and linear concurrency scaling, without a specialized engine, CDC pipeline, or separate security model to manage. Remember that 258ms-on-a-billion-rows claim? That was one query, once, on a product still in Preview. Interactive tables hit sub 125ms latency on a billion-row table and sustained it across 1,000 concurrent connections on a feature that’s already GA.可重复的基准测试结果很明确。Snowflake 的交互式仓库可提供生产级亚秒级延迟和线性并发扩展，而无需专门的引擎、CDC 流水线或需要管理的独立安全模型。还记得那个“10 亿行数据 258 毫秒”的声明吗？那是一个查询，一次性测试，且产品仍处于预览阶段。交互式表在 10 亿行表上实现了低于 125ms 的延迟，并在 1,000 个并发连接下持续保持，且该功能已全面上市。
But the throughput wasn’t even the biggest surprise — a standard Snowflake table, and even an external Iceberg table queried directly with zero copies, held up well against a purpose-built Interactive Table using your existing data.但吞吐量甚至不是最大的惊喜——标准 Snowflake 表，甚至是直接查询且零拷贝的外部 Iceberg 表，在使用您现有数据时，与专门构建的交互式表相比表现同样出色。
This blog was written with repeatability in mind. Your data and query patterns are different, so the real test is running it yourself. I ask those interested in real-time analytics to give this a spin whether your tables are standard, Iceberg, or Interactive. And, as with all Snowflake features, they continue to improve over time. Keep an eye on this space as it will only continue to mature from here.本博客的撰写旨在实现可重复性。您的数据和查询模式各不相同，因此真正的测试是您亲自运行它。我邀请那些对实时分析感兴趣的人试一试，无论您的表是标准表、Iceberg 表还是交互式表。而且，与所有 Snowflake 功能一样，它们会随着时间的推移不断改进。请密切关注此领域，因为它将持续成熟。
I’d love to hear your findings and continue the discussion in the comments.我很乐意听到您的发现并在评论中继续讨论。
