A practical guide to implementing operational ontologies in Snowflake without a dedicated graph database. Using automotive supply chain as the example domain, it explains how to store hierarchical data (BOMs, component taxonomies, supplier tiers) as node-edge tables, then precompute transitive relationships using closure tables built from recursive CTEs. Closure tables turn complex multi-hop graph traversals into flat, indexed SQL lookups that run in under a second even for 40,000+ component BOMs. The post covers the SQL to build closure tables, how to handle multiple relationship types (part_of, subClassOf, suppliedBy, locatedIn), scaling strategies, and how Snowflake Cortex Analyst, Cortex Search, and Cortex Agent can sit on top to enable natural language querying.
Table of contents
What’s an ontology, and why should an engineer care?The problem: graph traversal at query timeClosure tables: precompute the graph, query it flatThe same pattern for component classificationWhy HOPS = 0 rows matterHow it’s builtDifferent relationships, different closure tablesWhy this changes thingsWhere it gets powerful: ontology meets operational dataGet Morgan Adolfsson’s stories in your inbox“What’s the maximum lead time path for the brake system?”“Show me all quality incidents for electronic components across the Model Y”The cross-silo insightScaling closure tablesSort: