What Alation pioneered
Alation effectively created the modern data catalogue category, and its founding insight still holds up: the best information about your data is not in your documentation, it is in how people actually use it.
Instead of asking stewards to describe every table by hand, Alation parses query logs. It watches what analysts actually run against the warehouse, and from that behaviour it learns which tables matter, which joins are common, which columns are trusted, and who the de facto experts on a dataset are. That behavioural intelligence powers its catalogue: search that ranks assets by real usage, popularity signals, automatic identification of top users, and query recommendations as people write SQL.
Around that core, Alation built a full enterprise catalogue: a business glossary, stewardship and curation workflows, policy documentation, lineage, and broad connectivity across warehouses and BI tools. It has been deployed widely across large enterprises for over a decade, and many sizeable organisations run their data literacy and stewardship programmes on it.
Credit where due: query-log-driven discovery was a genuinely better idea than manual curation, and Alation's behavioural approach remains a real strength. If your problem is "thousands of tables, nobody knows which ones to trust," Alation attacks that problem with evidence rather than opinion.
This comparison is about a different question: what a catalogue, even an excellent one, structurally cannot do, and what to use when that gap is the actual problem.
What query logs can and cannot tell you
Alation's behavioural intelligence is built on observation. That is its power and its boundary.
Query logs tell you what happened. They do not decide what is allowed to happen. Alation can see that an analyst queried the customer table four hundred times last quarter, and from that it infers the table is important and the analyst is an expert. What it cannot do is stand in front of query four hundred and one and ask whether it should run. The warehouse executes the query; Alation reads about it afterwards. Observation is downstream of enforcement by definition.
This shapes everything a catalogue can promise:
- Trust flags are advisory. Alation lets stewards endorse, warn, or deprecate assets, and surfaces those flags where analysts work. A deprecation flag on a table does not stop anyone querying the table.
- Policies are documentation. You can record in the catalogue that a column is sensitive and access requires approval. The grant that makes that true lives in the warehouse, configured by a different team in a different tool, and the two drift independently.
- Lineage is a picture. Alation can show you what feeds what. It cannot guarantee the picture is complete, because it only sees the systems it crawls, and it cannot use the picture to block a breaking change. A diagram does not have a veto.
- The audit story is assembled, not recorded. When a regulator asks who accessed which field and under what approval, a catalogue deployment answers by stitching together warehouse logs, IAM history, and ticket trails. It is doable. It is also exactly the kind of manual evidence assembly that audits exist to penalise.
None of this is an Alation flaw. It is what "catalogue" means. Alation documents and observes a serving layer it does not control. Every catalogue, Alation, Collibra, Atlan, shares the same boundary, which is why we have written this same structural argument across all three: see Integrius vs Collibra and Integrius vs Atlan for how it plays out against each.
The drift problem, again
There is a second structural issue, and Alation's own strength makes it vivid. A catalogue is a copy of reality, refreshed by crawlers and log parsers. Reality moves continuously: schemas change, pipelines get rebuilt, owners leave, access roles accrete. The catalogue chases.
Alation chases better than most, precisely because query logs are a live signal rather than a static scan. But the gap never closes to zero, because the catalogue is architecturally a mirror, and mirrors lag. The day the auditor walks in, your catalogue describes the estate as it was at the last successful sync, minus everything the crawlers cannot see.
Now invert the architecture. Suppose the metadata were not a description of the serving layer but the configuration of it. The schema in the tool is the schema the API serves. The owner in the tool is the person whose approval gates access. The access rules in the tool are the rules the endpoint enforces on every call. Then drift is not reduced. It is impossible, because there is no second copy to fall out of sync. The documentation and the deployment are one object.
That is the architecture Integrius chose, and it is the cleanest way to state the difference: Alation's metadata describes reality; Integrius's metadata is the configuration of the layer that serves it.
Integrius: the runtime, not the index
Integrius is a self-hosted data product platform. It deploys entirely inside your infrastructure, air-gap capable, with zero SaaS dependencies and no phone-home, which matters because Alation, in common with most of the category, is SaaS-first in practice, and for some regulated estates that ends the conversation before features come up. We cover why in self-hosted data governance.
Integrius connects to your sources through 16 connector types: PostgreSQL, MySQL, MSSQL, Snowflake, BigQuery, Redshift, MongoDB, REST, GraphQL, Salesforce, Kafka, S3, CSV, Excel, JSON and event logs. From those sources it builds governed data products, and each one carries the governance machinery a catalogue can only describe:
- An accountable owner who controls the schema, the access rules, and the lifecycle.
- One stable, versioned API endpoint per business concept, so consumers integrate once against a contract instead of coupling to source schemas. This is how the N x M integration problem collapses to N + M.
- Enforced access control: RBAC with 4 built-in roles and 24 granular permissions, applied at the moment of serving. If access is not approved, the API call does not return data. There is no advisory mode and no path around the endpoint.
- A tamper-evident audit chain: every access and change recorded in an append-only log, hash-chained with HMAC or Ed25519. The audit answer is a query, not a project. For regulated industries, Integrius supports 21 CFR Part 11 e-signatures, enforces ALCOA+, provides GDPR atomic erasure, and maps to HIPAA, SOX, FISMA and NIST 800-53.
- A dependency graph with blast radius analysis: before a field changes, the owner sees every downstream product and consumer that breaks. Lineage with a veto, not a picture.
Standard Fields give the organisation a canonical schema with approval-workflow mappings, so business concepts stay consistent across products. Products compose into other products with entity-keyed joins across sources in real time, and materialised snapshots serve at sub-50ms p95, fast enough to sit in production application paths, not just analytics.
Discovery is not abandoned in this model; it is generated. Every product's schema, owner, documentation and lineage exist as live configuration, and Integrius Search federates search across products without a separate index. Optic, the AI analytics layer, answers plain-English questions over governed products, with inference on-prem via Ollama and RBAC enforced upstream of the model, so the AI can only see what the asker is allowed to see.
Feature comparison
| Dimension | Alation | Integrius |
|---|---|---|
| Category | Enterprise data catalogue | Self-hosted data product platform |
| Founding idea | Learn the estate from query-log behaviour | Govern data on the serving path itself |
| Core job | Discover, document, steward | Govern and serve data as products |
| Governance model | Advisory: flags, policies, documentation | Enforced: unapproved calls return no data |
| Serves data | No | Yes, one versioned API endpoint per product |
| Metadata accuracy | Crawled and inferred, lags reality | Is the serving configuration, cannot drift |
| Discovery | Behavioural, usage-ranked, a core strength | Generated from served products, federated search |
| Lineage | Visualised across crawled systems | Dependency graph with blast radius, enforceable |
| Audit of access | Assembled from warehouse and IAM logs | Tamper-evident hash-chained log, built in |
| Compliance tooling | Policy documentation and stewardship | 21 CFR Part 11, ALCOA+, GDPR erasure, HIPAA/SOX/FISMA/NIST mapped, enforced |
| Deployment | SaaS-first | Self-hosted, air-gap capable, no phone-home |
| Pricing basis | Not public; negotiated enterprise contracts | Per governed data product, published |
Pricing
Alation does not publish list pricing. As with the rest of the enterprise catalogue category, expect negotiated contracts, and expect total programme cost to include implementation and the ongoing curation effort that keeps any catalogue trustworthy. At large-enterprise scale, catalogue programmes commonly run to six figures annually once that is counted honestly. That spend can be worthwhile; it should just be compared like for like, as a programme cost rather than a licence line.
Integrius publishes pricing on a single axis, governed data products in production:
- Pilot: EUR 5,000 per month, up to 20 products, Optic lite included.
- Enterprise: EUR 18,000 per month, up to 50 products.
- Platform Lite: EUR 22,000 per month, up to 75 products.
- Platform: EUR 320,000 per year for 100+ products, with Search and Optic included.
Search and Optic are EUR 100k per year add-ons on the mid tiers. All 16 connectors are included at every tier, and there is no per-seat, per-row, or per-connector metering. The cost of the platform tracks the number of governed products you run, which is also the number that tracks the value you are getting, and it stops the slow bleed we described in the hidden tax of data integration.
When to choose Alation
This section exists because a comparison that always ends in "buy ours" is not worth your time.
Choose Alation when the problem is literacy and discovery across a huge, heterogeneous estate. If you have thousands of tables across warehouses, lakes, and BI tools, and the daily pain is "which of these five revenue tables is the real one," Alation's behavioural, usage-ranked discovery is exactly the right medicine, and it works across systems Integrius does not serve and will never see.
Choose Alation when you are building a stewardship and data culture programme: glossaries, certified definitions, expert identification, analyst enablement. Its query intelligence makes stewardship evidence-based instead of opinion-based, and a decade of enterprise deployments shows in the workflow maturity.
Choose Alation when you do not want to change your serving architecture. A catalogue layers onto what you have. Integrius is the serving layer; adopting it means routing consumers through governed endpoints, which is a real architectural decision, not a tool install.
And as with the other catalogues, coexistence is legitimate: Alation as the estate-wide index and literacy layer, Integrius as the governed runtime for the data products that carry regulatory or commercial weight.
Decision guide
Reduce it to the failure you are actually trying to prevent.
If the failure is ignorance, analysts using the wrong table, duplicated effort, tribal knowledge walking out of the door, buy discovery, and Alation is one of the best discovery products ever built.
If the failure is control, an unapproved query returning PII, an audit you cannot evidence, a schema change silently breaking downstream consumers, then no amount of observation fixes it, because observation happens after the fact. Control lives on the serving path. That is where Integrius sits: accountable owners, enforced access, tamper-evident audit, blast radius before the change instead of an incident after it.
A catalogue tells you, with impressive accuracy, what happened to your data. A runtime decides what is allowed to happen to it. Know which sentence describes your problem before you buy either, because the budgets are similar but the outcomes are not interchangeable: discovery does not become enforcement at any spend level, and enforcement does not become estate-wide discovery just because the products it serves are well documented.
See enforced governance on your own infrastructure. Explore Integrius Core or read the technical brief.
