Snowflake support

Count supports importing and on-the-fly conversion of Snowflake YAML files into Count catalog views and datasets. This allows teams migrating from Snowflake, or maintaining a Snowflake-based semantic layer alongside Count, to reuse their existing Snowflake definitions. Not all Snowflake features are supported. See Limitations for details.

#General support

Snowflake YAML files are just one type of third-party file that Count Metrics supports. This support includes:

  • on-the-fly (or automatic) conversion for teams who want to continue maintaining their semantic layer definitions outside of Count;
  • once-off (or manual) conversion for teams who want to fully migrate their existing semantic layer definitions into Count; and
  • extending automatically converted views and definitions to adjust them without needing to change the third-party files.

See here for more details on how Count Metrics supports third-party files generally. This page will focus just on the specific details of this related to Snowflake YAML files.

#Snowflake Conversion Details

Count supports two Snowflake YAML specifications:

  • Semantic View YAML files: YAML files used to generate native Snowflake schema objects. Use measures for row-level measures. Relationship types are auto-inferred rather than explicitly declared. Adds access_modifier support on fields and metrics.
  • Semantic Model YAML files (legacy): YAML files stored on a Snowflake stage, used with Cortex Analyst. Uses facts for row-level measures (equivalent to measures). Supports explicit join_type and relationship_type on relationships.

See the Snowflake documentation for the full specification.

Both specs share the same underlying structure and are converted using the same process. Differences are handled transparently - for example, measures and facts are treated identically.

#What Is Converted

  • Snowflake semantic model or semantic view -> Count dataset
  • Snowflake table with base_table -> Count view with table source
  • Snowflake dimension -> Count field (no aggregate)
  • Snowflake time dimension -> Count field with timeframes
  • Snowflake fact / measure -> Count field, with aggregate if default_aggregation is set
  • Snowflake metric -> Count field with aggregate (parsed from expression)
  • Snowflake metric with filter -> Aggregate CASE WHEN expression
  • Snowflake model-level metric (single-table reference) -> Field on the referenced view (see Model-Level Metrics)
  • Snowflake relationship -> Count join
  • Snowflake foreign_keys / unique_keys -> Inferred joins (when no explicit relationship covers the same table pair)
  • Snowflake primary_key -> Primary key fields on view

#Supported Types

  • varchar, nvarchar, char, nchar, character, text, string -> converted to string
  • number, decimal, numeric, fixed -> converted to integer or number depending on the scale
  • int, integer, bigint, smallint, tinyint, byteint -> converted to integer
  • float, double, real, double precision, float4, float8 -> converted to number
  • boolean -> converted to boolean
  • date, datetime, timestamp -> converted to date
  • time -> converted to string (no time type in Count Metrics)

#Unsupported Types

variant, array, object, binary, varbinary, geography, geometry. Fields with unsupported types are commented out in the converted output with an explanation.

#Supported Aggregation Types

count, count_distinct, sum, sum_distinct (converted to sum), avg, average (converted to avg), average_distinct (converted to avg), median, mode, max, min, stddev_pop, stddev_samp, var_pop, var_samp.

#Supported Timeframes

Time dimensions are converted with the following timeframes: year_trunc, quarter_trunc, month_trunc, week_trunc, day_trunc, hour_trunc, day_of_week, and the raw (untruncated) value.

#Relationships and Joins

Snowflake relationships are converted to Count joins. The converter supports:

  • Explicit relationships defined at the model level with relationship_columns or expr
  • Implicit relationships inferred from foreign_keys on tables (when no explicit relationship already covers the same table pair)
  • relationship_type mapping: one_to_one, one_to_many, many_to_one, many_to_many
  • join_type mapping: inner, left / left_outer (default), right / right_outer, full / full_outer
  • For foreign key–derived joins, the relationship type is inferred based on whether the foreign key column(s) are declared as unique keys on the source table

#Model-Level Metrics

Metrics defined at the semantic model level (outside of any table) are distributed to table views by analyzing tableName.fieldName references in the metric expression:

  • Single-table reference: assigned to that table's view as a normal metric field
  • Multi-table reference: assigned to the first referenced table's view but commented out (cross-view metric expressions are not supported)
  • No table reference: assigned to the first table's view but commented out

#Limitations

Certain Snowflake features do not have direct equivalents in Count. During conversion, unsupported definitions are included as commented sections with an inline explanation, so nothing is silently dropped.

#Private Access Fields

Fields with access_modifier: private_access are commented out in the converted output, as Count does not have an equivalent access control concept for individual fields.

#Cross-View Metric Expressions

Model-level metrics that reference fields from multiple tables are not supported. These are commented out with an explanation.

#Snowflake-Specific Properties

Properties such as synonyms, sample_values, cortex_search_service, cortex_search_service_name, is_enum, and unique on fields are not converted. non_additive_dimensions on metrics is also not supported. These are noted as unsupported properties in comments on the generated output.

#Verified Queries and Custom Instructions

verified_queries, custom_instructions, and module_custom_instructions at the model level are not converted, as Count does not have equivalent concepts.

#Filters

Snowflake filters defined on tables are not converted, as Count does not have an equivalent filtering concept at the view level.

#Cross Join Type

The cross join type is not supported. Relationships with this join type are commented out.

#Field Expression SQL

Field expressions can only use a limited SQL dialect that Count uses in various places such as visuals and low-code cells (see here). Complex SQL constructs, warehouse-specific functions, or deeply nested subqueries may not convert successfully.

Last updated: 03/08/26