STORAGE_SERIALIZATION_POLICY: Schema, database, and account values apply to externally managed Iceberg writes (Pending)

Attention

This behavior change is in the 2026_08 bundle.

For the current status of the bundle, refer to Bundle history.

When the 2026_08 bundle is enabled, a write to a writable externally managed Iceberg table in a standard Snowflake database uses the STORAGE_SERIALIZATION_POLICY value from the table, then the schema, then the database, then the account.

This change does not apply to an Iceberg table in a catalog-linked database. Writes to those tables already use the policy from the table, schema, database, or account. It also does not apply to an Iceberg table that uses Snowflake as the catalog. When you create one of those tables, Snowflake stores the policy that is in effect for its schema on the table, and later writes use that stored value.

Before the change:

A write uses STORAGE_SERIALIZATION_POLICY only when the parameter is set on the table. A value set on the schema, the database, or the account is ignored. If the parameter is not set on the table, the write uses OPTIMIZED.

OPTIMIZED encoding and compression ensure the best table performance within Snowflake. COMPATIBLE encoding and compression ensure interoperability with third-party compute engines.

The remote table in this example already exists in the external catalog and has two columns, a number and a string. The schema value is COMPATIBLE, and the table itself has no value:

ALTER SCHEMA my_schema SET STORAGE_SERIALIZATION_POLICY = 'COMPATIBLE';

CREATE OR REPLACE ICEBERG TABLE my_schema.my_iceberg_table
  EXTERNAL_VOLUME = 'my_external_volume'
  CATALOG = 'my_rest_catalog_integration'
  CATALOG_TABLE_NAME = 'my_remote_table_name';

INSERT INTO my_schema.my_iceberg_table VALUES (1, 'a');

The INSERT writes data files with OPTIMIZED encoding. Snowflake does not use the COMPATIBLE value on the schema.

After the change:

The same write uses the first STORAGE_SERIALIZATION_POLICY value found on the table, the schema, the database, or the account. In the previous example, the INSERT writes data files with COMPATIBLE encoding, because that value is set on the schema and the table has no value of its own.

A value set on the table still takes precedence:

ALTER ICEBERG TABLE my_schema.my_iceberg_table SET STORAGE_SERIALIZATION_POLICY = 'OPTIMIZED';

INSERT INTO my_schema.my_iceberg_table VALUES (2, 'b');

This INSERT writes data files with OPTIMIZED encoding.

Snowflake resolves the policy each time it writes. A later change to the schema, database, or account value applies to subsequent writes, unless the table itself has a value set. If the parameter is not set at any of these levels, the write uses OPTIMIZED, which is the default.

Snowflake does not rewrite data files that were written before the bundle is enabled. Only new writes use the resolved policy.

How to update your code

To find where the policy is set, check each level:

SHOW PARAMETERS LIKE 'STORAGE_SERIALIZATION_POLICY' IN TABLE my_schema.my_iceberg_table;
SHOW PARAMETERS LIKE 'STORAGE_SERIALIZATION_POLICY' IN SCHEMA my_schema;
SHOW PARAMETERS LIKE 'STORAGE_SERIALIZATION_POLICY' IN DATABASE my_database;
SHOW PARAMETERS LIKE 'STORAGE_SERIALIZATION_POLICY' IN ACCOUNT;

If you set STORAGE_SERIALIZATION_POLICY = 'COMPATIBLE' on the schema, database, or account so that third-party engines can read the files, no action is required. New writes to these tables now use that value. COMPATIBLE files might be larger and slower to scan in Snowflake than OPTIMIZED files.

To keep OPTIMIZED encoding for one table, set the parameter on the table:

ALTER ICEBERG TABLE my_schema.my_iceberg_table SET STORAGE_SERIALIZATION_POLICY = 'OPTIMIZED';

Ref: 2428