Is a customer-managed Alation alternative the right fit for your constraint?
If your policy requires the catalog to stay inside your own network, the customer-managed edition of Alation is the version you can host, and self-hosted OpenMetadata or DataHub can meet that same hosting requirement. The trade-off is operating work: with Alation Cloud Service, Alation runs and upgrades the instance, while with either open-source option your team owns the servers or Kubernetes cluster, the databases, the search layer, connector schedules and every upgrade. This section helps you decide whether that operating load is one your team can carry.
This page covers three things: what customer-managed Alation does not receive, because Alation documents several features as available only in Alation Cloud Service, how OpenMetadata and DataHub compare on features, upgrades and operating effort, and how each option is deployed. Alation's own comparison of Alation Cloud Service and customer-managed Alation is the right starting point for confirming which features apply to your plan. Ask Alation in writing which of the cloud-only features your organization would give up, and check whether any of them are on your current roadmap.
Before you compare platforms, confirm three points in your own environment: which Alation features your users depend on, how many people will administer the new catalog, and whether an existing Kubernetes platform or a bare metal host pool is available. OpenMetadata documents production deployments on Kubernetes or bare metal, and DataHub is deployed with Helm charts, so your infrastructure choice shapes the effort. Treat the feature gap and the staffing estimate as the two inputs that decide whether a self-hosted catalog is the right fit.
What a customer-managed Alation alternative must support on your infrastructure
Keeping a catalog on your own infrastructure makes four requirements non-negotiable: data stays in your environment, your team runs the platform, connectors reach sources inside your network, and sign-in runs through your identity provider. Each one needs a check against your own policy before you compare products.
Catalog data stays in your environment
Alation offers two models: Alation Cloud Service, where Alation runs the instance on its servers, and customer-managed Alation, where you host and maintain the software. Your constraint points to the second model, or to a self-hosted open-source catalog. Confirm where metadata, sample values, profiling output and search indexes are stored, and which third-party services receive any of them, including AI features and telemetry.
Your team installs and upgrades
Customer-managed software moves install, patching and upgrade work to your staff, so the upgrade path becomes an operating cost. OpenMetadata documents production deployment with Helm charts on Kubernetes and on bare metal, and its 2.0 release includes breaking changes that must be planned before upgrading. Ask each vendor for its upgrade runbook, rollback method and support window for older versions.
Connectors reach sources inside your network
Warehouses, BI tools and pipelines that sit on private networks need ingestion components that can reach them. OpenMetadata lists more than 130 connectors, and DataHub lists more than 150 integrations, but connector coverage does not prove network reach. Confirm which connectors run inside your network, where credentials are held, and whether ingestion jobs can be scheduled without outbound internet access.
Identity runs through your own SSO
Catalog access should follow your existing identity provider, not a local user store that drifts from HR records. DataHub supports OpenID Connect sign-in with providers such as Google, Okta and Azure AD, but on self-deployed DataHub Core the operator must configure the frontend server. Confirm group mapping, role assignment, session lifetime and how removed staff lose access.
Audit and access evidence stays yours
Governance reviews ask who changed a glossary term, who saw restricted tables and who owns each asset. Self-hosted platforms store these records in your database and logs, so their retention, export and backup become your responsibility. Ask each candidate which change and access events it records, how long they persist by default, and how an auditor can export them without vendor help.
Which Alation features stay out of reach when you host it yourself
Several Alation features are documented as available only in Alation Cloud Service, so a customer-managed installation will not have them. Alation's documentation lists the Alation Agent, the Microsoft Teams and Slack integrations, the Chrome Extension, OAuth 2.0 API authentication and AWS PrivateLink connectivity on Enterprise+ plans as cloud-only. Before you decide, check the current Alation documentation comparing Alation Cloud Service with customer-managed Alation, and confirm the exact feature set in your contract and plan tier, because Alation's list changes over time and the cloud-only list has been growing.
Each gap affects a self-hosted team differently. If your analysts ask data questions in Teams or Slack, a customer-managed catalog means either losing that channel or building your own bot against the API, and someone must own that code after go-live. The Chrome Extension, which surfaces catalog context inside other web tools, is similarly lost. OAuth 2.0 API authentication matters most for automation: if your pipelines, governance scripts or the export jobs you run before a migration depend on it, confirm which authentication method the customer-managed release accepts and plan token rotation and secret storage accordingly. The Alation Agent is also cloud-only, so confirm what the self-hosted edition offers in its place before counting on it.
AWS PrivateLink is the gap most tied to network design. If your security team relies on private connectivity to reach the catalog without traffic crossing the public internet, a self-hosted OpenMetadata or DataHub deployment in your own VPC or cluster gives you that control directly, because you decide the network path. Note that DataHub's managed product also lists PrivateLink, so that feature is not a reason to stay with Alation alone. Write down each cloud-only feature your users depend on today, mark whether it is needed, replaceable or retired, and ask Alation to confirm in writing which of them are unavailable to your deployment type.
How OpenMetadata and DataHub compare as a customer-managed Alation alternative
This table compares OpenMetadata and DataHub Core on license, hosting fit, deployment paths, upgrades and trade-offs for teams that must keep a catalog on their own infrastructure. Read each row against your own hosting constraints, since both projects are self-hostable but differ in operating model. The main takeaway is that both meet a self-hosting requirement, while the managed editions from Collate and DataHub Cloud are separate paid products.
| Criterion | OpenMetadata | DataHub Core |
|---|---|---|
| License | Apache License 2.0, maintained by Collate, which also offers commercial enterprise capabilities and premium support | Apache License 2.0, with DataHub Cloud sold separately by the company behind DataHub |
| How it meets the hosting requirement | Runs in your own Kubernetes clusters, on bare metal or in Docker for evaluation, so catalog data stays in your environment | Runs on your own Kubernetes using Helm charts, with Docker quickstart for trials, so catalog data stays in your environment |
| Deployment options | Helm charts on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes; bare metal with Java 21 and PostgreSQL or MySQL | Helm charts from the acryldata/datahub-helm repository plus a separate prerequisites chart for Kafka, database, search and graph index |
| Upgrade path | Versioned releases with documented breaking changes in 2.0, including credential configuration and Python 3.12 image rebuilds; review release notes before upgrading | Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed; confirm the process for your chart version |
| Managed edition | Collate offers managed OpenMetadata, commercial support and AI features | DataHub Cloud adds data quality monitoring, compliance forms, access request workflows and an SLA-backed service |
| Main trade-offs | Operating effort sits with your team; confirm connector coverage for your sources and which Alation features you need to replace | Requires operating Kafka, Elasticsearch and a graph index; confirm SSO setup for self-deployed Core, which the operator configures |
How to deploy OpenMetadata or DataHub under an on-premises constraint
This sequence takes a team from choosing a hosting target to a running, SSO-protected catalog inside its own network, with an upgrade routine that checks breaking changes before each move.
Confirm the hosting target first
The platform team, with the security and data owners, decides where the catalog will run: a Kubernetes cluster (on-premises, or an EKS, AKS or GKE cluster the organization already controls), bare metal without Kubernetes, or Docker for a local trial only. OpenMetadata documents production deployments on Kubernetes with Helm charts and on bare metal, with Docker Compose for evaluation. DataHub documents Kubernetes with Helm charts and a separate prerequisites chart, with a Docker quickstart for trials. Write the choice down with the reasons, because it decides the server, database and search components in every later step. The step is done when the target and its owner are recorded in the project plan and the security team has accepted it.
Size servers against the documented minimums
The infrastructure team sizes the nodes or servers using the minimums in the vendor documentation as a floor, not a target. For OpenMetadata bare metal, the stated minimum server size is 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. For DataHub on Minikube, the Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies, and Kafka, the metadata services and search all add load. Production sizing depends on the number of connectors, assets and users, so ask the vendor or a partner to confirm figures against your own estimate. The step is done when a sizing sheet lists each node, its CPU, memory and storage, and the capacity headroom the team agreed on.
Provision the database and search services
The database and search tier is provisioned before the application. For OpenMetadata bare metal, the prerequisites are MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. DataHub needs Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch or OpenSearch for search, and a graph index on Neo4j or Elasticsearch. Confirm which of these your organization already operates under backup and patch policies, and reuse them where the vendor documentation allows. Place each service inside the network boundary, restrict access to the application nodes, and enable the backups your recovery policy requires. The step is done when each service is reachable from the application tier, backups have completed a test restore, and the connection details are stored in your secrets manager rather than in configuration files.
Deploy the application with Helm or bare metal prerequisites
The platform engineers install the application. On Kubernetes, OpenMetadata is deployed with Helm charts, and DataHub is deployed with the acryldata/datahub-helm chart plus its prerequisites chart. On bare metal, OpenMetadata requires Java 21 on the host before installation. Pin chart and image versions in version control so every environment runs the same release. Check the release notes for the version you install, and record the exact version in your runbook. The step is done when the pods or services report healthy, a test user can sign in locally, and a sample connector run completes without errors.
Configure OIDC single sign-on
The identity team connects the catalog to the corporate identity provider. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator must configure the frontend server directly, while DataHub Cloud enables OIDC through its interface, so this work is a real cost item only for self-hosted installs. For OpenMetadata, review the security documentation for the authentication options your version supports and confirm them against your environment. Test sign-in with a standard user, an administrator and a user who should be denied, and confirm that group membership maps to the roles you intend. The step is done when the login flow is verified, local break-glass access is documented and restricted, and the identity provider's audit logs show the test sign-ins.
Run connectors inside the network
The data engineering team runs each ingestion connector from inside the network that can reach the source system, so credentials and metadata never leave the boundary. OpenMetadata lists more than 130 connectors, and DataHub lists more than 150 integrations, so confirm that each source you need, including any on-premises or VPC-locked systems, is supported in your chosen version. Store source credentials in a secrets manager, schedule ingestion, and confirm that the lineage and profiling settings match your data protection rules, since profiling can read sample rows. The step is done when each priority source completes a scheduled run, the run history is retained, and the team has reviewed which fields and samples the catalog now stores.
Plan upgrades with a breaking-change review
The platform team sets an upgrade routine before the first production release. OpenMetadata 2.0 includes breaking changes to check first: embedding credentials move into an llmConfiguration block, the Databricks auth format changes, custom ingestion images must be rebuilt for Python 3.12, and Great Expectations must be migrated to 1.3 before upgrading. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, so allow for that job in your change window and take a database backup beforehand. Test each upgrade in a non-production copy, review the release notes for every intermediate version, and keep a rollback plan. The step is done when a staging upgrade has passed, the change record lists the breaking changes and their owners, and the production window is approved.
Choosing OpenMetadata or DataHub by team environment
OpenMetadata fits teams that want a single self-hosted service with a clear production path on Kubernetes or on bare metal. The project documents production deployments on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes using Helm charts, and also on bare metal without Kubernetes, with Docker Compose reserved for evaluation. It is a good match for platform teams that already run Kubernetes and want standard charts, and for organizations with fixed virtual machines that prefer a bare metal install.
- Bare metal prerequisites: The bare metal guide lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Minimum server sizing: The documented minimum server is 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage.
- Upgrade planning: Version 2.0 contains breaking changes, including moved embedding credentials, a new Databricks auth format and a Python 3.12 rebuild of custom ingestion images, so plan a staging upgrade.
- Managed edition: Collate offers managed OpenMetadata, commercial support and AI features, so confirm with Collate which capabilities it covers.
Confirm your Kubernetes or VM standards, your database and search service versions, and whether your team already runs Elasticsearch or OpenSearch before you select this path.
DataHub fits teams that are comfortable operating a event-driven metadata architecture and already run Kubernetes, Kafka or both. Its open-source edition, DataHub Core, is deployed with Helm charts from the acryldata/datahub-helm repository, plus a separate prerequisites chart for its dependencies. It suits data platform teams with strong lineage and many connector sources, and organizations that want Apache-2.0 code with a wide integration list.
- Core components: The Kubernetes guide lists GMS, the MAE Consumer, the MCE Consumer and the Frontend, which need Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch.
- Local resource needs: The guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, and the Docker quickstart requires 8 GB of RAM.
- Upgrade behavior: The Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, so budget time for that job in each upgrade window.
- Identity setup: On DataHub Core, the operator configures the frontend for OIDC sign-in with providers such as Google, Okta or Azure AD.
- Managed edition: DataHub Cloud adds data quality monitoring, AI anomaly detection, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink, so ask the vendor which of these your team would need.
Confirm that your team can operate Kafka and the graph index, and whether your sign-in provider and Kubernetes capacity match the chart requirements before choosing this path.
Team profile often decides the choice more than features do. A platform team with Kubernetes experience and a need for event-driven metadata changes may find DataHub's architecture familiar. A smaller team that wants fewer moving parts, or that runs on bare metal, may find OpenMetadata's single-service model easier to operate. Both platforms need a named owner for upgrades, connector credentials and search index health.
- Kubernetes-first platform teams: Both projects have Helm-based paths, so the deciding factors are dependency count and upgrade work.
- Teams without Kubernetes: OpenMetadata documents a bare metal install, while DataHub's documented production path is Kubernetes.
- Teams with Kafka already in production: DataHub's use of Kafka may reuse existing skills and operations.
- Teams that need managed options later: Compare Collate's offer for OpenMetadata with DataHub Cloud, including what each includes and excludes.
- Small pilot groups: Start with the team that owns the most important sources and the Alation features it uses most.
Write down your environment, your owners and your required features, then check them against the vendor documentation before you commit.
Neither platform should be chosen from documentation alone. A pilot against your own sources shows whether connectors, lineage and permissions behave as expected in your environment. Use a representative slice that includes your most-used warehouse, a BI tool, a pipeline tool and at least one source with sensitive data. Measure what the team actually operates, not only what the feature list says.
- Connector coverage: Run the connectors for your warehouses and BI tools, and record which fields and lineage edges appear.
- Search and discovery: Test search with real user questions from your analysts and stewards.
- Resource draw: Track memory and storage use on the sizes you plan to run, and compare with the documented minimums.
- Upgrade rehearsal: Perform one upgrade in a staging environment and time the work.
- Access and sign-in: Test your identity provider, role mapping and audit logging.
Ask each vendor or its partner to confirm which features and support levels apply to your deployment before you finalize the pilot scope.
Evidence an auditor will ask for from a self-hosted catalog
A self-hosted catalog is only as defensible as the records behind it. The cards below cover the evidence most assessors request for a customer-managed catalog, from where metadata lives to how sources are connected and restored. DeployOpen prepares these systems and evidence for assessments, but independent auditors and certification bodies issue any audit report or certification.
Architecture record of data locations
Document where catalog metadata is stored, which database, search index and graph or streaming components hold it, and which network zones they sit in. For OpenMetadata this covers the server, database and search service, and for DataHub the GMS, consumers, frontend, Kafka and storage layers. Confirm that every component runs inside your own cloud account, data center or air-gapped network and that no metadata leaves it through a default setting.
Access logs and SSO configuration
Assessors usually ask who signed in, from where, and under which identity provider settings. Record the OIDC or SAML configuration, the enforced login method, role assignments and where authentication logs are shipped. On self-deployed DataHub Core the operator configures the frontend for OIDC, so keep the exact configuration under change control and confirm that local accounts are disabled or tightly restricted.
Upgrade and breaking-change review records
Keep a dated record of each upgrade, the release notes reviewed and the sign-off that approved it. OpenMetadata 2.0 introduced breaking changes, including a new llmConfiguration block for embedding credentials and a Databricks auth format change, and required Great Expectations 1.3 before upgrading. DataHub's Helm chart runs a system-update job on upgrades. Show the test environment run and the rollback plan for each change.
Backup and restore test results
A backup that has never been restored is not evidence. Document the backup scope for the metadata database, the search index and any configuration or secrets, the schedule and the retention period set by your policy. Then record a restore into a separate environment, the time it took, and whether lineage, glossary terms, ownership and curated descriptions came back intact. Repeat the test after major upgrades.
Connector inventory and source access
Maintain a list of every connector, the source system it reads, the service account it uses, the permissions granted and the owner who approved it. This shows which data sources the catalog can see and which metadata, including sample data if profiling is enabled, leaves each source. OpenMetadata lists more than 130 connectors and DataHub more than 150 integrations, so the inventory should be limited to the sources you have approved.
Customer-managed Alation alternative questions buyers ask
What drives the total cost of replacing customer-managed Alation with OpenMetadata or DataHub?
The cost is the sum of components, and each one is paid to a different party. Your side pays for servers or Kubernetes capacity, the database and search services, and the staff who run them. Connector setup and content migration are one-time efforts, while upgrades, monitoring, backups and on-call support recur every year. Costs rise with the number of data sources, the volume of metadata, the number of connectors you must build or tune, and how much curated content (descriptions, glossary terms, ownership) you move across. Ask any provider for a quote that separates one-time work from recurring support, lists each source to be connected, and states who owns the infrastructure after handover. Your existing Alation subscription cost is a separate line to compare against.
How long does a self-hosted OpenMetadata or DataHub deployment take?
The timeline depends on scope, not on the software alone. The main drivers are the number of sources to connect, whether you run Kubernetes or bare metal, how quickly your platform team can provision the database, search and messaging dependencies, and how much curated Alation content must be extracted and mapped. Security review, identity provider setup and network approvals often take longer than the installation itself. A fixed-scope engagement sets the deliverables and milestones in writing before work starts, so the timeline follows from the agreed scope. Ask for the timeline as a list of milestones tied to named sources and acceptance tests.
What must our team provide before a catalog migration can start?
Your team needs to supply access and decisions before any build work begins. Typically this includes a list of data sources and their owners, an inventory of Alation features in use (lineage, glossary, custom fields, articles, Compose queries), credentials for source systems, and a Kubernetes cluster or hosts that meet OpenMetadata or DataHub prerequisites. You will also need an identity provider for single sign-on, network paths for connectors, backup storage, and named stewards to validate migrated descriptions and ownership. Confirm these items with your own security and platform teams, because approval lead times vary by organization.
Can our own engineers run a self-hosted catalog without a partner?
Yes, if your team has Kubernetes or Linux operations skills, database administration experience and someone who owns the connector configuration. Both projects are Apache-2.0 licensed and publish deployment documentation, so an internal team can install and operate them. The harder part is ongoing ownership: monitoring the search and database tiers, applying upgrades on a schedule, keeping connectors current with source changes, and supporting stewards. A partner can take on any of these as a fixed-scope project or as a retainer. Decide which of these functions you will staff internally before choosing an approach.
Do we need Collate or DataHub Cloud to run self-hosted OpenMetadata or DataHub?
No. Both projects are open source under the Apache License 2.0, and the self-hosted editions do not require Collate or DataHub Cloud. Collate offers managed OpenMetadata, commercial support and AI features, and DataHub Cloud adds features such as data quality monitoring, compliance forms, access request workflows and a managed uptime SLA. These are optional paid services. Check the feature list for your use case before committing, because some capabilities you use in Alation may not have an open-source equivalent, and the managed products are the vendors' route to them.
How do upgrades differ between OpenMetadata 2.0.x and DataHub 1.7.x?
Both projects publish frequent releases, but the upgrade work differs. OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. Maintenance releases in the 2.0 line arrive roughly every one to two weeks, so your plan must include regular patching. DataHub's Helm chart runs a system-update job during upgrades to apply schema changes and reindex search when needed, so you should plan for reindexing time and test in a non-production environment. Confirm the current release notes for your target version before scheduling any upgrade.
Is a self-hosted catalog cheaper than keeping Alation customer-managed?
It depends on your scale, existing skills and what you need to keep. Customer-managed Alation still requires your team to host, install and maintain the software, so part of the operating effort already exists. A self-hosted open-source catalog removes the license fee but adds connector development, content migration and possibly more platform staff time. Build a comparison that includes the same operating tasks on both sides, a count of the Alation features you depend on, and the staff time your team would commit. Ask a provider to show the one-time and recurring costs separately so the comparison is like for like.
What is a fixed-scope engagement for a self-hosted data catalog?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen deploys a catalog under an on-premises constraint
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a customer-managed Alation alternative, that means a catalog such as OpenMetadata or DataHub running in your cloud account, data center or air-gapped network, with the controls and evidence your reviewers ask for.
How we scope
- We confirm which Alation features your teams use today and which of them are cloud-only.
- We inventory data sources, connectors, identity providers and network zones that the catalog must reach.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen platform on your Kubernetes cluster or bare metal, following its published production guidance.
- We configure connectors, OIDC single sign-on, lineage ingestion and the search and database dependencies.
- We test access controls, backups and restores, and upgrade procedures in a non-production environment first.
How we hand over
- We document architecture, sizing, runbooks, upgrade steps and the connector configuration your team will maintain.
- We prepare control descriptions and evidence for compliance assessments, while independent auditors issue any opinion.
- We train your platform and data teams so day-to-day operation stays in your hands after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
- Retainers can cover release tracking, reviewing breaking changes and planning upgrade windows with your change board.
- Ask any provider to confirm which support, backup and upgrade tasks sit in the quote and which remain with your team.
