Snowflake changed the cost model beneath newly clustered tables

Snowflake has made Optima Clustering generally available and, from September 1, switched newly clustered tables to the new engine. Existing clustered tables remain on Clustering Classic indefinitely, and changing an existing table’s clustering key does not migrate it. That split matters: two tables in the same account can now receive different clustering behavior and be billed under different models while both charges still appear under the same Auto Clustering service type. Snowflake’s product post Snowflake documentation

The bill moves from compute to ingestion

Clustering Classic bills for serverless compute used to organize and maintain clustered tables. Optima instead uses an ingestion formula: gigabytes ingested multiplied by 0.007 credits per GB and an “overlap factor” between zero and one. Snowflake says append-only data that arrives naturally aligned with its clustering key can approach zero clustering cost, while updates that change clustering-key values typically carry an overlap factor of one. Snowflake documentation

That makes write shape—not only query volume—a cost variable. For teams exposing warehouses to analytics agents or text-to-SQL systems, generated reads do not directly create Optima clustering charges. But the tables those agents query may be maintained by pipelines, corrections or agent-driven write workflows whose update patterns now affect the overlap factor. The practical FinOps question is therefore no longer simply “how much serverless clustering compute ran?” but “which ingest and update patterns produced the billed credits?” Snowflake documentation

Performance behavior changes too

Optima expands the clustering-key length from Clustering Classic’s first five bytes per key column to as much as 1 KB across all key columns. Snowflake says this fixed an internal case where values shared the same five-character prefix; its product post also reports that Block saw more than a 90% reduction in execution time on one specific table after enabling Optima and recreating it, while cautioning that results vary by workload and table design. Snowflake documentation Snowflake’s product post

What operators should check

Snowflake exposes the active engine through SYSTEM$CLUSTERING_INFORMATION and adds a VERSION column—OPTIMA or CLASSIC—to AUTOMATIC_CLUSTERING_HISTORY. That history includes credits, bytes and rows reclustered, but the Account Usage view can lag by up to three hours. Snowflake also warns that its estimator does not yet return Optima maintenance-cost estimates; maintenance is instead bounded at 0.007 credits per ingested GB before the overlap factor reduces it. Automatic Clustering documentation AUTOMATIC_CLUSTERING_HISTORY reference

The immediate operational move is to inventory which tables are on each version, baseline credits by VERSION, and segment append-heavy tables from update-heavy ones. For agent-facing analytics, that gives teams a defensible way to separate query-cost changes from storage-maintenance changes before attributing a bill increase to generated SQL.