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.