Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
When Snowflake Horizon is enough and when it is not: the edition gates, the coverage limits and a decision rule, every claim cited to Snowflake documentation.
Updated on
Snowflake Horizon Catalog is good, it is bundled, and for a large number of teams it is the correct and final answer. That is not the conclusion most articles on this question reach, and it is the one the documentation supports whenever an estate genuinely runs on one platform.
The useful work is defining where it stops, precisely enough that you can put the boundary in a budget request. Two things decide that: which edition of Snowflake you are on, because most of the governance surface is gated behind Enterprise Edition, and how much of the estate you care about is actually a Snowflake object. Everything below is read from Snowflake documentation on 6 September 2026, and the exact pages are listed at the end so you can check any of it.
Read this as a decision rule rather than a verdict. The answer changes with the shape of the estate, not with the size of the company.
| Your situation | What to do | Why |
|---|---|---|
| Everything you govern is a Snowflake object and you are already on Enterprise Edition | Use Horizon. Buy nothing. | The metadata is already in the account, the governance features are already paid for, and a second catalog describes the same assets a second time. |
| Everything you govern is a Snowflake object but you are on Standard Edition | Price the Enterprise Edition upgrade first, before you price a catalog | Lineage, quality monitoring, classification, tag based masking and access history all require Enterprise Edition. The upgrade may cost less than a platform, or it may not, but it is the comparison that matters. |
| Snowflake is the center of the estate but a lake, a Postgres instance or a BI layer is in scope | Use Horizon inside Snowflake and add a layer that covers the rest | Horizon governs Snowflake objects and Iceberg tables in an external REST catalog. Other systems arrive only as OpenLineage nodes, and only if something pushes them in. |
| You need to know that a pipeline broke, not that a rule failed | Add observability, whichever catalog you use | Native anomaly detection covers volume and freshness on two system metrics. Everything else is a threshold you set yourself and a notification you configure yourself. |
| You are regulated and have to show one control set across the whole estate | A per platform governance layer will not close the audit | Evidence assembled separately for each platform is the thing auditors ask you to reconcile. One control set across systems is a different product from a good warehouse catalog. |
Start with what Snowflake says it is, because the framing matters. The Horizon Catalog documentation page opens like this:
Horizon Catalog is the agentic catalog for all your data, whether it is inside or outside of Snowflake. It is open, interoperable, and compatible with any engine, any data, and any cloud.
The page then groups the product into four areas. Discovery and connection covers Apache Iceberg tables, the Iceberg REST Catalog API, external tables, catalog linked databases and the Internal Marketplace. The AI context layer covers semantic views, end to end data lineage, automatically generated descriptions and object tagging. Governance and trust covers data quality monitoring, sensitive data classification, data protection policies, AI guardrails, the model registry, access control and cross engine policy enforcement. Business continuity covers database and account replication across regions and accounts.
That is a real product and the list is not padded. Every item on it exists and is documented. What the page does not do, anywhere, is state an edition requirement for a single one of them. Those live on the individual feature pages, and they are the reason this question has a cost answer at all.
This is the table that decides the answer, and it is assembled from the requirement note at the top of each feature page rather than from any single Snowflake summary. If you are on Standard Edition today, this is the list of things you do not currently have.
| Capability | Edition required | What the documentation says |
|---|---|---|
| Data lineage in Snowsight | Enterprise Edition or higher | The lineage page states, verbatim, "This feature requires Enterprise Edition (or higher)." |
| External lineage over OpenLineage | Enterprise Edition or higher | Generally available, and the page carries the same Enterprise Edition requirement. |
| Data quality monitoring with data metric functions | Enterprise Edition | The data quality introduction states, verbatim, "Data Quality Monitoring requires Enterprise Edition." Upgrading from a lower edition requires contacting Snowflake support. |
| Anomaly detection on data quality metrics | Enterprise Edition or higher | Documented as a preview feature available to all accounts that are Enterprise Edition or higher. |
| Sensitive data classification | Enterprise Edition or higher | The classification page states, verbatim, "Sensitive data classification requires Enterprise Edition or higher." |
| Tag based masking policies | Enterprise Edition | The page states, verbatim, "This feature requires Enterprise Edition." |
| Tag propagation | Enterprise Edition or higher | Creating and setting tags is available to all accounts. The documentation notes that advanced capabilities, including tag propagation, require Enterprise Edition or higher. |
| ACCESS_HISTORY | Enterprise Edition or higher | The reference page states, verbatim, "Access History requires Enterprise Edition (or higher)." Note that the editions comparison page lists it under Standard Edition; the feature page is the more specific source and it is the one quoted here. |
| Time Travel beyond 1 day | Enterprise Edition or higher | The standard retention period is 1 day and is enabled for all accounts. Only on Enterprise Edition and higher can permanent databases, schemas and tables be set to any value up to 90 days. Transient and temporary objects stay at a maximum of 1 day on every edition. |
Two consequences follow, and both are usually missed. The first is that the edition is not a governance line item. It applies to every credit the account consumes, so upgrading to get lineage and quality monitoring changes the rate on your entire compute bill. Snowflake publishes those rates through a regional calculator rather than a fixed public list, so the only honest instruction is to model your own consumption before assuming the bundled option is the cheap one.
The second is that quality monitoring and classification carry serverless compute costs on top of the edition. Data quality billing is documented as occurring only when a scheduled data metric function is computed on an object, which is a fair model, but it does mean the cost scales with how many checks you run and how often. Bundled is not the same as free.
This is the sentence that does the most work in Horizon marketing and the one most likely to be misread. It has a precise documented scope, and that scope is three things.
A catalog linked database is a Snowflake database connected to an external Iceberg REST catalog, which syncs automatically to detect namespaces and Iceberg tables. Snowflake documents it as supported when you use a catalog integration for Iceberg REST, with tutorials covering AWS Glue and Databricks Unity Catalog as the external catalog. The boundary is explicit in the documentation: you can create schemas, externally managed Iceberg tables or database roles in a catalog linked database, and creating other Snowflake objects is not currently supported. Replication and cloning are not supported either.
So the "outside Snowflake" story is an Apache Iceberg story. It is a genuinely good one if your lake is Iceberg. It does nothing at all for a system that is not.
An external table is documented as a feature you use to query data stored in an external stage as if the data were inside a table in Snowflake. The supported locations are Amazon S3, Google Cloud Storage and Microsoft Azure storage. They are read only, no data manipulation statements are permitted, and XML file formats are not supported. This extends the catalog over files in a bucket. It does not extend it over a database.
External lineage is generally available and requires Enterprise Edition or higher. Tools send OpenLineage COMPLETE events as JSON to a Snowflake REST endpoint, and Snowflake documents configuration for dbt and Apache Airflow specifically, noting that any tool with an OpenLineage integration can be configured the same way. Column level lineage is supported through the columnLineage facet. The documented limits are the part to plan around: external lineage events are retained for one year, an event carries a maximum of 15,000 lineage edges, the account limit is 20,000 external lineage edges in total, the default node type is External Node, and OpenLineage version 2 is not supported.
Read that account limit again, because it is the shape of the feature. Twenty thousand edges across the whole account is a useful bridge to a transformation tool and an orchestrator. It is not an inventory of another platform. And nothing arrives unless you build and maintain the push.
What this adds up to is simple. Horizon governs Snowflake objects, Iceberg tables it can reach through a REST catalog, and files in a bucket. Everything else appears as a node on a graph if you wire it up, and does not appear at all if you do not. Anything you need to search, tag, classify, quality test or attach a policy to has to be a Snowflake object.
Snowflake data quality monitoring works through data metric functions, which you attach to an object and put on a schedule. The system library is grouped into six categories: accuracy, freshness, schema, statistics, uniqueness and volume. Accuracy is by far the largest, covering blank counts and percentages, case format violations, future timestamps, invalid JSON, invalid numeric type casts, negatives, nulls, special characters, untrimmed strings and zeros. Statistics covers averages, minimums, maximums, medians, approximate quantiles, standard deviation, variance and string length measures. Uniqueness is three functions: ACCEPTED_VALUES, DUPLICATE_COUNT and UNIQUE_COUNT. Schema is one, SCHEMA_CHANGE_COUNT. Volume is one, ROW_COUNT.
That is a solid library and it covers most of what a team writes by hand in the first year. The documented limits are where the planning happens.
Snowflake does train an algorithm on historical values and flag results outside a predicted range, which removes the threshold problem for the metrics it covers. Two documented constraints define how far that goes. ROW_COUNT and FRESHNESS are the only system data metric functions that support anomaly detection, and the feature is documented as a preview feature available to Enterprise Edition accounts and higher.
It also needs history before it does anything. The documentation calls for at least two weeks of data for a frequently running function, or at least two data points for an infrequent or trigger based one, and recommends 60 days of data to detect anomalies with a high degree of confidence. Until then the status reads TRAINING_IN_PROGRESS. Sensitivity is adjustable across low, medium and high to manage false positives.
So volume and freshness get learned baselines. Null rates, duplicate counts, distribution shifts and every accuracy metric get a number you picked. That is the honest position, and it is a reasonable one for a warehouse to take. It is also the gap that observability products exist to fill, which is a separate decision from the catalog decision and should be made separately.
Notifications are configured, not assumed. You set DATA_QUALITY_MONITORING_SETTINGS on the database with a specification that names whether notifications are enabled, the email recipients, the notification integrations, a cooldown in hours and whether object metadata is included. Email addresses must be verified first, and the role needs MANAGE DATA QUALITY on the account plus usage on the notification integration. Channels are email and external systems such as Slack through webhooks. Once enabled at database level, every object in that database with an attached data metric function generates notifications, and you switch individual ones off by setting DATA_QUALITY_NOTIFICATION to FALSE on the association.
None of that is difficult. All of it is work somebody has to do and keep doing, and it is the part that quietly decides whether the native option really was cheaper.
Lineage in Snowsight requires Enterprise Edition or higher. The graph covers tables, dynamic tables, external tables, Iceberg tables, views, materialized views, semantic views, stages, datasets, feature views and models. Column lineage is supported between columns in table like objects, with one documented exception: column lineage is not currently supported for semantic views. The graph reveals objects incrementally, one step at a time upstream or downstream from your selection, rather than rendering a whole dependency tree at once.
The list of things it does not track is the part worth writing down, because these are the gaps you discover during an incident rather than during an evaluation.
For a Snowflake to Snowflake trace this is strong, and it is free of the setup that external lineage requires. The question to ask about your own estate is where the trace has to start and end. If the answer is "from the ingestion job through to the dashboard", the warehouse graph is the middle of the picture and the two ends arrive over OpenLineage or not at all. Our own explainer on the ways lineage is captured and used goes into the difference between parsing a warehouse and stitching an estate, if that distinction is new.
Treat this as background rather than as a Horizon limitation or a criticism of Snowflake. It is a design decision, documented plainly, and it changes how you should read anything a catalog tells you about relationships between tables.
On standard tables, the constraints reference lists PRIMARY KEY, FOREIGN KEY and UNIQUE constraints as "Optional, not enforced". NOT NULL and CHECK constraints are listed as "Optional, enforced". Hybrid tables behave differently: PRIMARY KEY is required and enforced, FOREIGN KEY is optional and enforced for referential integrity, UNIQUE is optional and enforced, NOT NULL is optional and enforced, and CHECK constraints are not supported at all.
The practical consequence is that on ordinary Snowflake tables, a declared primary key is documentation. The engine accepts it, the optimizer may use it, and nothing rejects a duplicate. Any relationship diagram a catalog draws from those declarations is a statement of what somebody intended, not evidence of what is true in the data. If uniqueness and referential integrity matter to you, they have to be tested rather than declared: a DUPLICATE_COUNT or UNIQUE_COUNT data metric function on the key column, or the equivalent test in whatever quality layer you run. Assume nothing from the schema.
If all five of these hold, use Horizon and spend the money somewhere else. This is a real outcome for a lot of teams and there is nothing second best about it.
Any single one of these is a reason to evaluate a dedicated platform alongside Horizon rather than instead of it. Horizon keeps doing its job inside Snowflake either way.
The honest framing is that this is not a replacement decision. If your estate is Snowflake, Horizon is doing useful work and should keep doing it. The decision is about the layer that has to span systems, and about the capabilities the native layer leaves as your own engineering problem.
| Platform | What it covers natively | Where it stops |
|---|---|---|
| Decube | Catalog and discovery with a business glossary, custom attributes and verified and deprecated tags; column level lineage across systems with a structured approval flow on lineage changes; no code and custom SQL quality tests across 12 test types with dynamic thresholding, bulk configuration and alert grouping; pipeline health, freshness, volume, schema change detection and machine learning based anomaly detection, all first party; data contracts between producers and consumers with SQL based test enforcement; policy driven tagging, automatic PII classification, role based access, group management and approval workflows. | It is a second product to evaluate and justify when a bundled one already exists. If your estate really is one platform, that justification is hard and should be. Ask us for the current list of sources our quality engine monitors before you assume coverage of any specific system, because that list changes and we would rather you check it than take it from a blog post. |
| Snowflake Horizon Catalog | Discovery across Snowflake objects with Universal Search; object tagging, contacts for stewardship and automatically generated descriptions; semantic views; column level lineage inside the warehouse; sensitive data classification; data metric functions across six metric categories with configurable notifications; masking and row access policies; the Trust Center scanners; replication for continuity. | Most of that requires Enterprise Edition. Coverage outside Snowflake means Iceberg tables in an external REST catalog, files in cloud object storage, and OpenLineage nodes within a 20,000 edge account limit. Anomaly detection covers volume and freshness only and is in preview. Every other threshold and every notification route is yours to define and maintain. |
Two capabilities are worth calling out because they are the ones we would point at in this specific comparison rather than in general. The first is approval gated lineage: a structured approval flow on the lineage layer itself, so a change to a documented relationship is a governed event rather than a re render. Nothing in the Snowflake lineage documentation describes an equivalent, because the graph is derived rather than curated. If that matters to you, our lineage product page is the place to look at how the approval flow works.
The second is dynamic thresholding on quality tests, which addresses the exact gap the documentation describes: native anomaly detection covers ROW_COUNT and FRESHNESS, and everything else is a static number. Alongside it sit pipeline health monitoring, freshness, volume and schema change detection with machine learning based anomaly detection as first party features rather than a separate purchase, which is what our data observability page covers.
On cost, we publish ours, which is the only reason it is mentioned here. Starter is 175 US dollars per user per month, from 21,000 US dollars a year with a minimum of 10 users, and Growth is 225 US dollars per user per month, from 54,000 US dollars a year with a minimum of 20 users, on the Decube pricing page. Compare that against a modeled Enterprise Edition uplift on your actual consumption plus the serverless cost of the checks you intend to run, not against the word "included".
You do not need a proof of concept to answer this. You need four numbers and an hour.
If the count in step one is all Snowflake and the answer to step four is nobody, stop. Use Horizon, wire up the notifications properly, and put the budget into something that is actually missing. If either answer went the other way, you are not choosing between a catalog and a warehouse feature. You are choosing what covers the part of the estate the warehouse was never built to see. If the vocabulary here is new, our explainer on what a data catalog is and what it holds sets out the underlying concepts before you start comparing implementations.
For lineage that starts and ends inside Snowflake, Horizon is enough. Its lineage graph requires Enterprise Edition or higher and covers tables, dynamic tables, external tables, Iceberg tables, views, materialized views, semantic views, stages, datasets, feature views and models, with column level lineage between columns in table like objects. You need a dedicated tool when the trace has to reach outside the warehouse. Snowflake documents several things the graph does not track: objects in shared databases or the SNOWFLAKE database, temporary tables, deleted tables, tables used only for filtering or joining where no data moves downstream, and data movement performed by separate disjointed queries. Lineage from outside systems arrives only through the external lineage endpoint, which accepts OpenLineage events from tools such as dbt and Apache Airflow, retains those events for one year, and is capped at 20,000 external lineage edges per account. If your postmortem needs to name the ingestion job and the dashboard as well as the tables in between, that cap and that setup burden are the reason to look at a dedicated platform.
The Horizon Catalog page states no edition requirement, but the individual feature pages do, and most of the governance surface is gated. Data lineage in Snowsight, external lineage, sensitive data classification and ACCESS_HISTORY each state Enterprise Edition or higher. Data quality monitoring and tag based masking policies each state Enterprise Edition. Tag propagation requires Enterprise Edition or higher, although creating and setting tags is available to all accounts. Time Travel beyond the default 1 day, up to 90 days on permanent objects, also requires Enterprise Edition or higher. One inconsistency is worth knowing: the editions comparison page lists ACCESS_HISTORY under Standard Edition while the ACCESS_HISTORY reference page states it requires Enterprise Edition or higher. Because the Snowflake edition sets the rate on every credit the account consumes, not just on governance features, an upgrade to obtain these should be modeled against your real consumption rather than assumed to be cheaper than buying a platform.
Within a specific documented scope, yes. It covers Apache Iceberg tables held in an external Iceberg REST catalog through a catalog linked database, which syncs namespaces and tables automatically; Snowflake documents AWS Glue and Databricks Unity Catalog as external catalogs in its tutorials, and notes that only schemas, externally managed Iceberg tables and database roles can be created there. It covers files in Amazon S3, Google Cloud Storage and Microsoft Azure storage through read only external tables, which do not support data manipulation statements or XML. And it accepts lineage from external tools over an OpenLineage endpoint, capped at 20,000 external lineage edges per account with a default node type of External Node. What it does not do is make a system that is none of those things into a governed Snowflake asset. An operational database, a BI semantic layer or an ingestion tool cannot be searched, tagged, classified, quality tested or policy attached inside Horizon.
It does part of it natively and leaves the rest to you. Data quality monitoring uses data metric functions grouped into six categories: accuracy, freshness, schema, statistics, uniqueness and volume. You attach them to an object, set a schedule with an hourly default, and define expectations as comparisons. Anomaly detection, which learns a baseline instead of making you pick a number, is documented as a preview feature for Enterprise Edition accounts and supports only two system functions, ROW_COUNT and FRESHNESS. It needs at least two weeks of history before it activates and Snowflake recommends 60 days for high confidence. Notifications are configured per database through the DATA_QUALITY_MONITORING_SETTINGS property, with email or webhook based channels such as Slack. So freshness and volume get learned baselines, and null rates, duplicate counts and distribution shifts get thresholds a person chose and now maintains. That is the gap dedicated observability tooling addresses, and it is a separate decision from the catalog decision.
Not on standard tables. The Snowflake constraints reference lists PRIMARY KEY, FOREIGN KEY and UNIQUE constraints as "Optional, not enforced", while NOT NULL and CHECK constraints are listed as "Optional, enforced". Hybrid tables are different: PRIMARY KEY is required and enforced, FOREIGN KEY is optional and enforced for referential integrity, UNIQUE is optional and enforced, NOT NULL is optional and enforced, and CHECK constraints are not supported. The practical consequence for anyone reading a catalog is that a relationship drawn from a declared key on a standard table records what somebody intended, not something the engine has verified. If uniqueness or referential integrity matters, test it: a DUPLICATE_COUNT or UNIQUE_COUNT data metric function on the key column, or the equivalent test in whichever quality layer you run.
Time Travel has a standard retention period of 1 day, or 24 hours, enabled automatically for all accounts. On Standard Edition the retention period can be set to 0 or left at the default of 1 day. On Enterprise Edition and higher, permanent databases, schemas and tables can be set to any value from 0 up to 90 days, while transient and temporary objects remain capped at 1 day. ACCESS_HISTORY, which records the direct objects accessed, the base objects accessed, the objects modified and the policies referenced by a query, requires Enterprise Edition or higher and displays the last 365 days. It carries a latency of up to 180 minutes and does not log several things, including RESULT_SCAN operations, failed queries, intermediate views between base tables and direct objects, stream update operations and data movement from replication.
When any one of five things is true. A system outside Snowflake would appear in your incident postmortems, and it is not an Iceberg table in a REST catalog or a file in cloud object storage. You need to know a pipeline broke rather than that a rule failed, on more than the two metrics native anomaly detection covers. You need governance on the lineage itself, meaning an approval step before a documented relationship changes rather than a graph that simply re renders. People who need to read the catalog will never be given a Snowflake login. Or an auditor wants one control set evidenced across the estate rather than assembled platform by platform. If none of those is true and you are already on Enterprise Edition, use Horizon and spend the budget on something that is genuinely missing.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)