Dataplex alternative for multi-cloud and on-prem catalogs

Why a Dataplex alternative matters when your estate spans clouds and data centers

Dataplex catalogs Google Cloud resources automatically, but the rest of a multi-cloud estate needs custom work. If your analytics platform spans BigQuery, AWS data stores, Azure databases and on-premises Oracle or SQL Server instances, the question is not whether Dataplex works for Google Cloud. It is who builds and maintains the entries, lineage and ownership records for everything outside it. Each custom entry, script or home-grown connector becomes a system your team must version, schedule, monitor and repair when a source schema changes. Before deciding, inventory which sources sit outside Google Cloud, which of them hold regulated data, and which teams already own the metadata for them.

The second constraint is where metadata itself must live. A catalog holds table names, column descriptions, owners, lineage edges and sometimes sample values or classifications that can reveal sensitive structure. If your data residency or internal policy says that information must stay in your own accounts or data centers, a managed catalog that runs in another provider's environment needs to be checked against that rule, not assumed to comply. Ask the vendor where each metadata store is hosted, which regions and sub-processors are involved, and whether a connector can run inside your network without sending source credentials out.

The short answer is that a self-hosted OpenMetadata or DataHub deployment can ingest Google Cloud, AWS, Azure and on-premises sources into one catalog that you run yourself. Both are open source under the Apache License 2.0, and both use connectors instead of hand-built entries for many of the systems on your list. The trade-off is operational: you take on the hosting, upgrades, backups and search infrastructure that Dataplex hides from you. The sections that follow compare coverage, operating effort and migration steps so you can judge whether that trade is worth it for your estate.

What a multi-cloud and on-premises catalog must do

Dataplex covers Google Cloud resources well, so the questions for a replacement start where its native coverage ends. The requirements below set what a self-hosted catalog must reach, authenticate, govern and maintain across AWS, Azure and on-premises estates, and each card names the check to run before you commit.

Connector coverage across clouds

Count the sources you need to catalog in each cloud, including warehouses, BI tools and pipelines, and compare that list with the connector catalog of the candidate. OpenMetadata lists 130+ connectors and DataHub lists 150+ integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Confirm each connector version against your own source versions, because a listed connector does not guarantee support for every release of a database or BI tool.

Reaching VPC-locked and on-premises sources

A catalog can only read sources its ingestion workers can reach. Decide where the ingestion agents run, whether they sit in each cloud VPC or inside the data center, and how they reach databases without public endpoints. Self-hosted OpenMetadata can run on Kubernetes in each environment or on bare metal, so the ingestion placement is your design choice. Document the network paths and firewall rules before the pilot.

Single sign-on and access control

Map your identity provider to the catalog before users arrive. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD, but on self-deployed DataHub Core the operator configures the frontend server. Confirm how OpenMetadata authenticates users and which roles control editing, glossary changes and access to sensitive asset descriptions. Test group removal and offboarding as part of the sign-on design.

Lineage and governance features

Check which lineage types you need: table, column, dashboard, pipeline and metric lineage. OpenMetadata supports OpenLineage event integration, and DataHub supports column-level lineage. Governance needs usually include a business glossary, classifications, domains and data quality tests. Confirm whether approval workflows, compliance forms and access request processes are included in the open-source edition or only in the vendor's managed product.

Upgrade and backup operations

Plan who runs upgrades and who restores the metadata store. DataHub's Helm chart runs a system-update job to apply schema changes and reindex search when needed. OpenMetadata 2.0 introduced breaking changes, including new configuration blocks and a Python 3.12 rebuild of custom ingestion images, so read the release notes before each upgrade. Back up the relational database and search index together, and test a restore on a separate environment.

How OpenMetadata, DataHub and Apache Atlas compare for mixed estates

This table compares OpenMetadata, DataHub and Apache Atlas on the things that matter when Dataplex's native Google Cloud coverage is not enough: connector breadth, lineage, quality, deployment targets, licensing and paid add-ons. Use the rows marked for confirmation as a checklist against each source system you must catalog. The main takeaway is that both leading options are Apache-2.0 and cover non-Google sources, but each connector, and anything Dataplex does natively, needs to be verified in your own environment before you commit.

Capability	OpenMetadata	DataHub	Apache Atlas
License	Apache-2.0, maintained by Collate	Apache-2.0, company also sells DataHub Cloud	Apache-2.0, Apache Software Foundation project
Connector breadth	More than 130 connectors, including an OpenLineage connector	More than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau	Built for Hadoop ecosystem sources; confirm coverage for any non-Hadoop database or SaaS source
Connectors you need for on-premises databases	Confirm the exact connector and version for each on-premises engine in the connector list	Confirm the exact integration and version for each on-premises engine before scoping	Confirm whether a Hadoop or custom hook exists; otherwise plan custom development
Lineage	Table, column, dashboard, pipeline and metric lineage with OpenLineage events	Column-level lineage listed as a core feature	Lineage framework for Hadoop-style data flows; confirm fit for SQL warehouses
Glossary and classification	Glossaries, classifications and domains	Business glossary included in the open-source feature list	Classification-based governance; Apache Ranger integration for access control
Data quality	Data quality tests, profiling, freshness checks	Data quality assertions and monitoring; AI anomaly detection and compliance forms are DataHub Cloud features	Not a quality testing product; plan a separate tool
Deployment targets	Kubernetes on EKS, AKS, GKE or on-premises clusters, bare metal, Docker Compose for evaluation	Kubernetes with Helm charts, Docker quickstart for trials	Hadoop-oriented deployment; confirm the target stack before planning
Required services	Java 21, MySQL or PostgreSQL, Elasticsearch 9.x or OpenSearch 3.x	Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch or OpenSearch, and a graph index	Confirm storage and search backends for your Hadoop version
Commercial add-ons	Collate offers managed OpenMetadata, premium support and AI features	DataHub Cloud adds quality monitoring, access request workflows, a 99.5% uptime SLA and AWS PrivateLink	No vendor add-on comparable to the others; confirm commercial support providers
Native Dataplex coverage to replace	Automatic cataloging of Google Cloud resources must be rebuilt through connectors	Same: BigQuery and Looker ingestion must be configured, not automatic	Same: Google Cloud resources need custom ingestion

Where each catalog runs when sources sit in several clouds

When every source sits in one cloud region, the simplest layout is to run the catalog in that same region, on a Kubernetes cluster or a set of virtual machines in your own account. Both OpenMetadata and DataHub can sit next to the sources, so connectors reach databases and warehouses over private networking without crossing a public boundary. OpenMetadata documents production deployment on Amazon EKS, Azure AKS and Google GKE, and on bare metal, so the cluster choice follows your existing platform.

Catalog placement: Run the OpenMetadata server, database and search service in the same region and VPC or VNet as the sources.
OpenMetadata options: Use the Helm charts on EKS, AKS or GKE, or the bare metal path if you do not run Kubernetes.
DataHub dependencies: Plan for Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch or OpenSearch and a graph index, deployed with the acryldata/datahub-helm charts and the prerequisites chart.
Connector placement: Run ingestion workers inside the same network so each connector reaches its source privately.
Confirm: Whether your managed Kubernetes service and network policies allow the ingestion jobs to reach every source endpoint.

How to deploy a self-hosted catalog across clouds and data centers

This sequence moves a multi-cloud and on-premises metadata estate onto one self-hosted catalog, with each source inventoried, connected and checked before users rely on it.

Inventory sources and confirm connector coverage
Your team lists every system that holds metadata: BigQuery and other Google Cloud resources, AWS and Azure stores, and on-premises databases, warehouses, BI tools and pipelines. For each one, check whether OpenMetadata (more than 130 connectors) or DataHub (more than 150 integrations) has a maintained connector, and mark any gaps that will need custom ingestion. The output is a signed-off source list with a connector status for each entry, which becomes the scope for the rest of the work.
Choose OpenMetadata or DataHub
Decide between the two Apache-2.0 platforms using the inventory. OpenMetadata documents production deployment on Kubernetes or bare metal and exposes REST APIs, a Python SDK and an MCP server. DataHub centers on a metadata service with Kafka, a relational database, search and a graph index, and it is deployed through Helm charts. Confirm with the vendor or project which connector versions match your source versions. The output is a written decision record that names the platform and the reasons for it.
Size the platform from documented minimums
Start from the minimums in the vendor documentation, then size for your own volume. OpenMetadata's 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, with a server minimum of 2 vCPUs, 4 GB RAM and 20 GB storage. DataHub's Kubernetes guide notes that more than 7 GB of RAM is needed on Minikube for DataHub and its dependencies. Ask your platform team to confirm high availability, backup targets and network routes between each cloud and the data center. The output is a sizing sheet approved by infrastructure and security owners.
Deploy on Kubernetes or bare metal
Deploy the chosen platform in your own accounts or data centers. For OpenMetadata, use the Helm charts on EKS, AKS, GKE or on-premises Kubernetes, or the bare metal guide if you do not run Kubernetes. For DataHub, install the prerequisites chart for Kafka, the database and search, then the main chart from the acryldata/datahub-helm repository. Use Docker only for a trial. The output is a running environment that answers health checks and shows an empty catalog ready for configuration.
Configure OIDC single sign-on
Connect the catalog to your identity provider using OpenID Connect. DataHub supports OIDC providers such as Google, Okta and Azure AD, and on self-deployed DataHub Core your team must configure the frontend server. OpenMetadata's security documentation covers its own SSO options, so review them before you go live. Test sign-in with a group-restricted account and confirm that role mapping works. The output is a successful login through your identity provider and a documented list of administrative roles.
Run ingestion per source with secure credentials
Create one ingestion pipeline for each source, using a read-only service account in the source system. Store credentials in your secrets manager rather than in pipeline definitions, and restrict network paths so each connector reaches only its source. Start with one BigQuery dataset, one AWS store, one Azure source and one on-premises database to confirm access from each network. The output is a successful first run per source with entity counts that match what your data owners expect.
Validate lineage and metadata quality
Check that lineage crosses the boundaries that matter, such as a warehouse table feeding a dashboard or a pipeline that spans clouds. OpenMetadata supports table, column, dashboard, pipeline and metric lineage with OpenLineage events, and DataHub supports column-level lineage. Ask data owners to review ownership, glossary terms and classifications on a sample. The output is a short validation report listing confirmed lineage paths, known gaps and the owners who accepted the sample.
Set the upgrade path and test releases first
Agree a process for upgrades before production use. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so plan for that job in your change window. OpenMetadata 2.0 includes 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. Test each release in a non-production copy and back up the database and search indices first. The output is a tested runbook that names the owner of each upgrade step.

What moving off Dataplex changes for owners and ingestion teams

The biggest change is that ingestion stops being automatic. Dataplex discovers Google Cloud resources on its own, but with OpenMetadata or DataHub your team owns every source: each AWS, Azure or on-premises database, BI tool and pipeline needs a connector job that you schedule, monitor and repair when credentials rotate or schemas move. Ingestion teams should inventory every source feeding the catalog today, mark which ones Dataplex reaches automatically and which were loaded through custom entries, and assign an owner and a schedule to each. Confirm in the current connector documentation which sources each platform supports natively before you assume a connector exists.

Custom entries become connectors or API-based loads. Entries that were written by hand or by scripts against the Dataplex API need a target in the new catalog, either a connector for the source system or a scripted push through the REST APIs or the Python SDK that OpenMetadata provides. Stewards should expect to review these entries first, because scripted loads rarely carry the descriptions and ownership that people added by hand. Name the owner of each load job in your runbook so that a failed run does not silently leave stale metadata behind.

Curated metadata is the part that does not come across on its own. Descriptions, glossary links, owners and aspect-based fields maintained in Dataplex must be exported and re-mapped, and the Dataplex metadata export is the starting point for that work, with its curated fields as the input and the target catalog's glossary, custom properties and classifications as the destination. Plan the mapping as a reviewed table, not a one-off script, and have stewards sign off on the mapped results for each domain. The sibling pages on migrating to OpenMetadata and on the Dataplex export cover the field-level steps in detail.

Evidence auditors and data governance reviewers ask for

Auditors and governance reviewers rarely accept a catalog on its features alone. They ask how each source was connected, who can sign in and with what rights, how far lineage actually reaches, and whether the catalog can be restored and upgraded under control. The cards below list the records that answer those questions for a self-hosted OpenMetadata or DataHub estate that spans Google Cloud, AWS, Azure and on-premises databases. DeployOpen can prepare these artifacts, but independent auditors and certification bodies decide whether they are sufficient.

Ingestion configuration per source

Keep one versioned ingestion definition for each source, covering the connector type, the service account or database role used, the filters that limit scope, and the schedule. Store these files in Git so every change has an author and a review. For a multi-cloud estate, this record shows that the BigQuery, S3, Azure and on-premises databases were each connected under a named, least-privilege identity rather than a shared administrator. Ask your team to confirm that secrets are referenced from a secrets manager, not written into the configuration.

Access and SSO settings

Record how users sign in, which identity provider issues tokens, which groups map to catalog roles, and who holds administrator rights. In DataHub Core, the frontend OpenID Connect settings are configured by your operator, so the configuration file and the change history become the evidence. Include the list of local accounts that remain, the reason each exists, and how they are disabled. Reviewers will check that no shared login exists and that removing a person from the identity provider removes catalog access.

Lineage coverage records

Maintain a register that states, for each critical dataset, whether table, column and pipeline lineage was captured, and by which connector or OpenLineage event feed. Gaps matter in governance reviews because they show where a change to a source column could break a report without warning. Record the date of the last successful lineage run and the known exceptions, such as tools without a connector. Confirm the coverage against the connector list for your specific sources before you promise it to a reviewer.

Backup and restore tests

A catalog holds metadata, not source data, but it still needs recovery. Document what is backed up for the metadata database, the search index and any graph index, how often, and where copies are stored. The evidence that matters is a dated restore test that rebuilds a working catalog in a separate environment and reports the time taken and any manual steps. Note that search indices can often be rebuilt from the database, so record which component is authoritative and confirm this with the platform's documentation for your version.

Upgrade records

Keep a change record for every platform upgrade that names the source version, the target version, the release notes reviewed, the breaking changes assessed and the test results. OpenMetadata 2.0 shipped breaking changes such as moving embedding credentials into an llmConfiguration block and migrating Great Expectations to 1.3 before upgrading. DataHub's Helm chart runs a system-update job on upgrades, so record its output. Reviewers use these records to judge whether the platform is kept within vendor support and changed under approval.

Questions buyers ask before choosing a self-hosted catalog

Should we choose OpenMetadata or DataHub for a multi-cloud estate?

Both are Apache-2.0 catalogs that cover AWS, Azure, Google Cloud and on-premises sources, so the choice usually turns on operating model and team skills. OpenMetadata lists more than 130 connectors and documents production deployment on Kubernetes or bare metal, with a Python SDK and REST APIs. DataHub lists more than 150 integrations and column-level lineage, but its Core edition runs as several services that depend on Kafka and a search index. Test both against a sample of your real sources, including your on-premises databases, before you decide.

What drives the cost of a self-hosted data catalog?

The cost comes from four components: infrastructure, platform operations, connector maintenance and staff time. Infrastructure is recurring and depends on your sources and volume. OpenMetadata's bare metal documentation lists minimum server sizing of 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. Production sizing is larger. DataHub's Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, which is a local test figure, not a production one. Connector upkeep and upgrades recur with every source version you add.

How much Kubernetes or bare metal operations work should we expect?

Expect ongoing operations work in every option, because a catalog is a stateful platform with a database, a search index and ingestion jobs. OpenMetadata documents Helm charts for Amazon EKS, Azure AKS, Google GKE and on-premises Kubernetes, and a bare metal path that needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. DataHub uses Helm charts from its own repository plus a prerequisites chart, and its Helm chart runs a system-update job on upgrades to apply schema changes and reindex search. Ask your platform team which of these fits your existing clusters before choosing a path.

What should a quote for a self-hosted catalog include?

A quote should follow from a written scope, not a generic package. Ask for the source inventory and connector list, the deployment target (Kubernetes or bare metal, and in which cloud or data center), the identity integration, the lineage and data quality requirements, the backup and upgrade approach, and the handover documentation. Also ask whether the quote covers connector build, testing of each source, and the first upgrade. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your environment, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts.

How much work will our own team have to do?

Your team will provide access, data owners and decisions, and will keep the platform running after handover. Work for your staff includes approving metadata ownership and glossary terms, confirming which sources are in scope, and joining upgrade tests. OpenMetadata 2.0 includes breaking changes, such as 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. Plan staff time for those upgrade checks each time you move to a new release.

Can we run a self-hosted catalog ourselves without outside help?

Yes, if your team already runs Kubernetes or database clusters and has someone who can own the search and streaming dependencies. Both projects publish quickstarts for evaluation, including Docker Compose for OpenMetadata and the DataHub Docker quickstart, which needs Docker with 8 GB of RAM and Python 3.10 or later. Production is a different task. Ask whether your team can handle SSO configuration, which in DataHub Core must be set up by the operator through OpenID Connect, backups, and upgrades. If any of these are new skills, a fixed-scope implementation with documented handover is a common option.

Do managed options like Collate or DataHub Cloud change the decision?

They change who runs the platform, not whether the code is open source. Collate offers managed OpenMetadata, commercial support and AI features, and DataHub Cloud adds features not in open source, including data quality monitoring, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink. If your main concern is operating effort, compare those managed prices and terms against the infrastructure and staff time of self-hosting. If your main concern is data residency or control, confirm where each managed service stores metadata and who can access it before you assume it fits.

How the work is scoped and handed over

Every DeployOpen engagement for a multi-cloud or on-premises catalog starts with a written scope. Before any work begins, the scope, deliverables and timelines are agreed in writing, so the decisions that drive effort are visible to both sides: which catalog (OpenMetadata or DataHub), which sources sit in AWS, Azure, on-premises databases and Google Cloud, where the platform runs, and which Dataplex entries, glossary terms and lineage must be carried over. Ask for the scope to list each source system by name, with its connector and the credentials model it uses, because that list is what determines the ingestion work. Timelines should be stated as milestones tied to those deliverables, not as open-ended effort.

DeployOpen plans, implements, integrates, hardens, backs up and documents the platform inside your own infrastructure, whether that is a Kubernetes cluster you already operate, a set of virtual machines, or an air-gapped network. For OpenMetadata, that work covers the deployment model (Helm on Kubernetes or bare metal, as described in the OpenMetadata deployment documentation), database and search services, single sign-on, backup and restore procedures for the metadata store, and an operator runbook. For DataHub, it covers the Kubernetes components, Kafka, search and graph index, and the upgrade process. Confirm in the written scope who holds the cloud accounts, the secrets and the administrator roles at handover, so that the client team can run the catalog without the implementation partner.

Ongoing support, upgrades and continuous testing are available as retainers, and they are separate from the fixed-scope build. Upgrades deserve explicit scoping, because the pace of open-source releases is quick: the OpenMetadata 2.0 release notes list breaking changes that must be handled before an upgrade, and the DataHub Helm chart runs a system-update job on upgrades that a team needs to plan around. Ask what a retainer covers in terms of patch windows, version support and incident response, and what is excluded. The cost of a retainer recurs, while the build is one-time, so compare the two as separate line items in any quote.

How DeployOpen deploys a catalog across your clouds and data centers

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source catalogs such as OpenMetadata or DataHub inside your own cloud accounts, data centers or air-gapped networks. For a multi-cloud estate, the work starts with which sources must be connected and where the catalog itself should run.

How we scope

We list every AWS, Azure, Google Cloud and on-premises source that must be cataloged, with owners and access paths.
We agree which Dataplex metadata, glossary terms and descriptions move, and which are rebuilt in the new catalog.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen platform in your environment, on Kubernetes with Helm or on bare metal, following the vendor's documented prerequisites.
We configure connectors for each source, including network paths to on-premises databases that sit outside Google Cloud.
We integrate single sign-on, set up lineage ingestion, and test ingestion, search and access controls before cutover.

How we hand over

We deliver architecture, configuration, runbooks and ingestion schedules so your team can operate the catalog.
We document backup, restore and upgrade procedures, including pre-upgrade steps for each release.
We prepare control and evidence records for compliance assessments, while independent auditors perform any formal assessment.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers.
We track upstream releases and plan upgrades around breaking changes listed in each release note.
Ask us to confirm the support scope, response expectations and what a retainer excludes before you sign.

Google Cloud Dataplex alternative for multi-cloud and on-premises catalogs