Which should a Google Cloud data team choose: Dataplex or OpenMetadata?
The choice usually starts with one of three triggers: a Dataplex renewal or billing review, the move off Data Catalog after its shutdown, or a growing need to control where metadata is stored and who operates the platform. Dataplex fits a Google Cloud-centric estate well. It is a managed service that catalogs Google Cloud resources automatically, so a team whose data sits mostly in BigQuery and other Google services gets coverage with little setup and no platform to run. OpenMetadata fits a different shape of estate: mixed or multi-cloud data, on-premises databases, and sources that Dataplex does not catalog automatically. It is Apache-2.0 licensed, lists more than 130 connectors, and can be deployed in your own Kubernetes cluster or on bare metal, so the team owns the platform, its upgrades and its backups.
The decision turns on three questions. First, where does the data live, and how much of it sits outside Google Cloud? Second, who will operate the platform: a platform team with capacity for Kubernetes, a database, a search service and regular upgrades, or a team that wants a managed service? OpenMetadata 2.0 also introduced breaking changes, so an upgrade is a planned task, not a routine patch. Third, how much custom governance is needed, such as glossaries, classifications, data quality tests and domains that must follow your own approval rules? Confirm with Google Cloud and with your own environment which Dataplex features your current contract includes, and list every source you need cataloged before comparing costs. The answers to these questions usually settle the choice more clearly than feature checklists do.
Which option fits which scenario
This table matches common estate and operating conditions to the platform that usually fits them better, with the reason tied to the condition that makes it matter. Read each row against your own estate: if the condition does not hold for you, the reason may not apply. Dataplex is the lower-effort choice when Google Cloud is the center of gravity, while OpenMetadata is the stronger fit once metadata must be controlled across clouds or on-premises systems.
| Scenario | Better fit | Reason and the condition that makes it matter |
|---|---|---|
| Nearly all data sits in BigQuery and Google Cloud services | Dataplex | Dataplex catalogs Google Cloud resources automatically, so the condition is that little metadata must come from outside Google Cloud. Confirm coverage for your specific resource types in Google's documentation. |
| Mixed AWS, Azure and Google Cloud estate | OpenMetadata | OpenMetadata uses connectors across warehouses, BI tools and pipelines, so one catalog can span clouds. The condition is that you need one place to search and govern assets in several clouds. |
| Significant on-premises databases | OpenMetadata | Self-hosted OpenMetadata runs inside your network, so connectors can reach databases that sit behind internal firewalls. Confirm each source connector and the network path before committing. |
| Strict data residency or metadata that must stay in your own environment | OpenMetadata | Self-hosting keeps the catalog, its database and search index in infrastructure you choose. The condition is that metadata itself is regulated, not only the underlying data. Confirm where Google Cloud-side exports and logs are stored. |
| Small platform team with no capacity to run stateful services | Dataplex | A managed service removes the need to operate the catalog, database and search tier. The condition is that nobody on the team can own upgrades, backups and capacity for a self-hosted stack. |
| Team willing to run Kubernetes or bare metal services | OpenMetadata | OpenMetadata supports Helm on Kubernetes or bare metal, and its 2.0 releases include breaking changes that need planned upgrades. The condition is that someone owns the platform on an ongoing basis. |
| Contractual uptime SLA required from the catalog vendor | Dataplex | Dataplex is a Google Cloud managed service, so availability is governed by Google's service terms. Self-hosting shifts uptime responsibility to your team, so check whether an SLA is a hard requirement and confirm its terms with Google. |
| Need for catalog-level control over lineage, glossaries and custom metadata | OpenMetadata | OpenMetadata supports lineage, glossaries, classifications, domains and programmatic access through its APIs and SDKs. The condition is that you need to extend the metadata model beyond what the managed service exposes. |
Automatic Google Cloud cataloging versus connector-based ingestion
The core difference is where the metadata comes from. Dataplex (Knowledge Catalog) discovers and catalogs Google Cloud resources with little setup on your side, so a team with most of its data in BigQuery and other Google Cloud services gets a populated catalog quickly. For anything outside that boundary, such as on-premises databases, AWS or Azure services, or SaaS tools, Dataplex needs custom entries or connectors that your team builds and maintains. OpenMetadata takes the opposite starting point: it ships with more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, and each connector runs as an ingestion workflow you schedule and configure. Automatic discovery saves the most effort when your estate is almost entirely Google Cloud and you do not need a catalog for sources beyond it. Connector-based ingestion saves effort when the estate is mixed, because one configured workflow per source replaces a set of custom integrations.
Before committing, verify the non-Google sources you actually use in each product. In Dataplex, confirm which of your systems can be represented through custom entries or a supported connector, who writes and updates those entries, and how their schemas and ownership will be kept current. In OpenMetadata, check each source against the connector list in the project's OpenMetadata GitHub repository, confirm the version of each connector against your source version, and plan the ingestion schedule and the service account each connector needs. A connector that is listed is not the same as one that covers your objects, so test a representative schema from each source before you count it as coverage. Also plan for upkeep: OpenMetadata connectors and ingestion images change between releases, and the 2.0 release notes list breaking changes that affect ingestion images, so budget time for testing upgrades.
Where metadata lives and who runs the platform
Dataplex runs as a Google-managed service, so Google operates the catalog and its storage. OpenMetadata is software you install and operate in your own cloud account, data center or cluster, which moves the operating, security and evidence work onto your team or your implementation partner.
Dataplex as a managed service
Dataplex Universal Catalog, renamed Knowledge Catalog in April 2026, is operated by Google Cloud. Upgrades, scaling and the underlying infrastructure sit with Google, and your team manages projects, IAM roles and entry configuration. Before comparing, confirm with Google which metadata is stored in regional or multi-regional locations and what Google's own terms say about where catalog data is processed.
OpenMetadata self-hosted on Kubernetes
OpenMetadata documents production deployment with Helm charts on Amazon EKS, Azure AKS, Google GKE or on-premises Kubernetes. Your team owns the cluster, the ingress, backups of the metadata database and the search index, and every upgrade. Plan these as recurring operating work, not a one-time install.
Bare metal and small footprints
For teams without Kubernetes, OpenMetadata documents a bare metal deployment that needs Java 21, a supported MySQL or PostgreSQL database and Elasticsearch 9.x or OpenSearch 3.x. Confirm your database and search services are sized and backed up separately, because they carry most of the catalog's state and load.
Data residency and network placement
A self-hosted catalog stores table names, column descriptions, lineage and sample-derived profiles in your environment. Decide whether OpenMetadata runs in the same Google Cloud project and region as BigQuery, or in a separate network with connector credentials and private paths to each source. Check that ingestion traffic does not cross regions you have not approved.
Identity and access controls
OpenMetadata's security documentation describes how authentication, authorization and access to the API are configured, so you must select an identity provider, map roles to teams and rotate service credentials for connectors. Review that the default settings meet your policy before any production data is ingested, and test that revoked users lose API access.
Compliance evidence you produce
Whichever platform you choose, your organization must produce its own access reviews, change records, backup restore tests and hosting documentation for an assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Ask your independent auditor which evidence they will accept before the design is fixed.
Licensing, editions and what the open-source edition excludes
OpenMetadata is released under the Apache License 2.0, and the project is maintained by Collate, which also sells commercial enterprise capabilities and premium support. The license lets you run, modify and redistribute the core platform without a per-seat license fee, but it does not tell you which features sit in the open-source release and which are reserved for Collate's paid offerings. Before you commit, list the capabilities your governance program needs, such as specific connectors, SSO configuration, data quality workflows, AI features, support hours and any managed hosting, and check each one against the open-source documentation and the current release notes. Ask Collate in writing which items are excluded from the community build.
Dataplex is a Google Cloud service, so its terms are set by Google's commercial agreement and its pricing documentation, not by an open-source license. Do not assume how it is billed or what it includes. Confirm in Google's pricing documentation how Knowledge Catalog usage and related services are charged in your region, which parts of Dataplex are tied to Google Cloud projects, and whether any feature you rely on, such as entry groups, aspect types or metadata export, carries its own charge. Write those answers down, because they form the baseline for comparing the total cost of an open-source deployment.
The practical risk runs in both directions. With OpenMetadata, the cost of a feature gap usually shows up as a decision to pay Collate, build the missing piece yourself, or drop the requirement. With Dataplex, the cost shows up when a catalog that depends on Google Cloud resources must also cover systems outside it. Put the open-source feature check and the Dataplex pricing check into the same review, so the renewal or migration decision rests on a documented feature list and not on license labels alone.
Cost components: what you pay for each option
Dataplex and self-hosted OpenMetadata are paid for in different places. One bills consumption to Google Cloud, the other moves cost into your own compute, data services and the people who run them, so compare both sides by component rather than by a single headline figure.
Dataplex consumption charges
Dataplex (Knowledge Catalog) is a managed Google Cloud service, so the recurring cost is set by Google and depends on how much metadata your projects generate and how often it is scanned, profiled or exported. Ask your Google account team for the current pricing for the features you plan to use, since catalog, quality and export charges can be billed separately. Confirm whether metadata export jobs and the Cloud Storage output they write add cost at your scale.
OpenMetadata compute and storage
Self-hosting moves the recurring cost into your cloud account or data center: Kubernetes nodes on EKS, AKS, GKE or on-premises clusters, or servers for bare metal. Size for the server minimums in the bare metal guide and then for your actual catalog, profiling volume and user count. Compute and storage costs rise with the number of ingested assets, profiler runs and retention of lineage history.
Database and search services
OpenMetadata stores metadata in MySQL or PostgreSQL and indexes it in Elasticsearch or OpenSearch, so each needs its own capacity, backup and high availability. Managed database and search services carry their own recurring fees, while self-run instances shift that work to your platform team. Check the supported versions in the prerequisites before you price either option.
Staff time for upgrades and connectors
The largest hidden cost is labor. OpenMetadata ships frequent maintenance releases, and 2.0 included breaking changes such as credential format moves and a Python 3.12 rebuild of custom ingestion images. Someone must own connector maintenance, upgrade testing and the Airflow-based ingestion schedule. Estimate this as recurring staff time in your own plan, and consider whether a retainer or an implementation partner covers it.
One-time migration and implementation
Moving from Dataplex means one-time work: deploying the platform, building BigQuery and other connectors, loading glossaries and descriptions, and replacing aspect types with custom properties and classifications. This effort is fixed in scope, not recurring, and it is the cost most affected by the number of entry groups and custom aspects you hold. Ask any provider for a written, fixed scope before comparing quotes.
Optional Collate and support fees
OpenMetadata is Apache-2.0 licensed, so the software itself carries no license fee. Collate, the company that maintains OpenMetadata, offers managed OpenMetadata, commercial support and AI features for a fee that is not in this comparison. Confirm with Collate what is included, what SLAs apply and how fees scale, and whether you need that support at all before you budget for it.
Operating effort for a self-hosted OpenMetadata catalog
Docker Compose is the path OpenMetadata documents for evaluation, not for production. It brings the catalog, its database and its search service up on one host, which makes it the fastest way for a team to test connectors, glossaries and lineage against its own Google Cloud data before committing to a platform. The effort here is low and almost entirely one-time, but it does not carry over unchanged to production.
- Host sizing: The server minimum is 2 vCPUs, 4 GB RAM and 20 GB storage, and the database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage. Running all three on one small host leaves little headroom for ingestion jobs.
- Scope of use: Use it to validate connector configuration, metadata quality and access patterns with a limited set of BigQuery datasets.
- Data handling: Test data still sits on a machine someone administers, so apply the same access and backup rules you would use for production.
- Migration to production: Plan to rebuild the environment on Kubernetes or bare metal rather than promoting the Compose host.
Confirm the current Compose file and image tags with the OpenMetadata deployment documentation before you start, because the 2.0 line changed ingestion images and configuration.
For production, OpenMetadata documents Helm-based deployments on Amazon EKS, Azure AKS, Google GKE and on-premises Kubernetes. On Google Cloud, GKE keeps the catalog close to BigQuery and other Google sources. Most of the recurring effort is cluster operations, database and search service care, and ingestion scheduling, and the cost components are the same whether you use managed or self-run services.
- Cost components: You pay for cluster nodes, the managed or self-run PostgreSQL or MySQL database, the search service, storage, and the people who operate them. Ask whether your team will run the database and search cluster itself or use managed equivalents.
- Sizing: The published minimums are a starting point. Production sizing depends on the number of assets, ingestion frequency and profiling depth, so load-test with your own catalog before you set capacity.
- Backups and recovery: Define backup for the metadata database and the search index, and test a restore, because the search index can be rebuilt but the database holds the curated content.
- Identity and access: Connect single sign-on and role mapping early, and review the OpenMetadata security documentation for the controls your auditors will ask about.
- Ongoing work: Upgrades, connector version changes and credential rotation recur. Schedule them as a standing task.
Before you commit, confirm the supported Kubernetes versions, Helm chart version and Google Cloud service configuration with the OpenMetadata deployment documentation and your own platform team.
Bare metal is the option for teams that do not run Kubernetes or that need the catalog on fixed virtual machines. OpenMetadata's bare metal guide lists its own prerequisites, and the team must install, patch and monitor every component itself. The one-time setup is larger than Kubernetes for many teams, and the recurring work shifts to operating system and service maintenance.
- Runtime prerequisites: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Component sizing: Give the server at least 2 vCPUs, 4 GB RAM and 20 GB storage, and give the database and search services at least 2 vCPUs, 2 GB RAM and 30 GB storage each, then size up for production load.
- Operations: Each service needs its own patching window, log collection, monitoring and restart procedure, and failover is designed by hand.
- Upgrades: Java, database and search version changes can each force a separate change, so keep them in one change plan.
- Staffing: Make sure the people on call know Java services, the database and the search engine, not only Google Cloud.
Confirm the exact supported versions and any hardware guidance with the bare metal deployment documentation before you size the environment.
Upgrades apply to every deployment model and are where most unplanned effort appears. OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases followed through 2.0.5 on October 8, 2026. The 2.0 release notes list breaking changes that must be handled before the upgrade, so treat the first move to 2.x as a project with its own test environment, not a routine patch.
- Breaking changes: Embedding credentials move into an
llmConfigurationblock, Databricks authentication uses a new format, and custom ingestion images must be rebuilt for Python 3.12. - Dependency migration: Great Expectations must be migrated to 1.3 before upgrading if you use it for data quality.
- Default behavior: Dynamic Sampling is now the profiler default, and MCP is enabled by default, so review profiling load and access exposure after the upgrade.
- Release cadence: Maintenance releases arrived about every one to two weeks, so plan a recurring review of which patch level you run.
- Testing: Run a copy of production metadata through the new version before cutover, and keep the previous version available for rollback.
Confirm the upgrade steps for your current version with the OpenMetadata 2.0 release notes before you schedule the change.
What a move from Dataplex to OpenMetadata involves
The sequence moves your catalog from a managed Google Cloud service to a self-hosted OpenMetadata instance that you control, with each stage ending in a check that the metadata matches what your teams rely on. Most of the effort sits in scoping sources, mapping Dataplex-specific metadata, and validating before cutover.
Scope the sources and owners
Start by listing every system your catalog must cover, including BigQuery datasets, any AWS, Azure or on-premises databases, BI tools and pipelines, and who owns each one. Confirm which Dataplex entry groups and projects are in scope and which can be retired. The step is done when the team signs off on a source inventory with named owners and a decision on what stays out of the new catalog.
Export Dataplex metadata
Run a Knowledge Catalog metadata export job at the organization, project or entry group scope you chose. The output lands as JSONL files in Cloud Storage, which you can query with BigQuery to review entries, descriptions, glossary links and aspect values. The step is done when a complete export is stored outside the working catalog and someone has checked row counts against the Dataplex console. The detailed procedure is covered in the sibling export guide.
Deploy OpenMetadata in your environment
Choose the hosting model first: Kubernetes with Helm on your cluster or a managed Kubernetes service, or bare metal for teams without Kubernetes. Provision the database and search service that OpenMetadata requires, and confirm the versions listed in the bare metal prerequisites. Docker Compose is suitable only for evaluation. The step is done when a non-production instance answers logins and API calls inside your network, and your security team has reviewed the deployment against the security documentation.
Configure connectors and ingestion
Set up OpenMetadata connectors for BigQuery and each other source in scope, and schedule ingestion so that technical metadata refreshes automatically. Dataplex catalogs Google Cloud resources without this setup, so this is the point where you take over that work. Service accounts and credentials should be stored according to your secrets policy. The step is done when each source shows its tables, columns and ownership in OpenMetadata and the ingestion logs show no unresolved failures.
Load glossaries and descriptions
Import the business glossary terms, descriptions and ownership assignments taken from the Dataplex export, and reconcile them with the entries ingestion created. Decide which Dataplex aspects become OpenMetadata custom properties and which become classifications or domains, since aspect types do not map one to one. The step is done when a sample of curated assets carries the same descriptions and owners as before, and each mapping decision is recorded in a shared document.
Validate lineage and data quality tests
Confirm that lineage from BigQuery and any OpenLineage-emitting pipelines appears at the table and column levels you need, and rebuild data quality tests, profiling and freshness checks in OpenMetadata where Dataplex used its own checks. Compare results for a set of critical tables against the current behavior. The step is done when data owners approve the lineage and test results for the in-scope assets, and any gaps are logged with an owner and a fix.
Run in parallel and cut over
Run OpenMetadata alongside Dataplex long enough for users to search, review and approve metadata in both, and confirm that search access, roles and the glossary workflow match what teams expect. Then update links, documentation and any integrations that point at Dataplex, and stop the scheduled exports and ingestion that feed the old catalog. The step is done when the cutover checklist is signed off, the Dataplex catalog is set to read-only or retired, and the team has a runbook for upgrades and backups.
Questions buyers ask before switching from Dataplex
How much does it cost to run OpenMetadata compared with Dataplex?
Dataplex is billed by Google Cloud as a managed service, so its cost sits on your Google Cloud invoice, while OpenMetadata is free to license under Apache-2.0 but costs money to run. The recurring costs are the compute and storage for the OpenMetadata server, its database and its search service, plus the platform engineers who operate them. The published minimum for a bare metal 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, according to the OpenMetadata bare metal deployment docs. Production sizing grows with the number of assets, connectors and profiling jobs, so ask for a sized estimate based on your own catalog. If you want vendor support, Collate offers commercial support and managed OpenMetadata, which is a separate cost line.
How much effort does a migration from Dataplex take?
Effort depends mainly on how much curated metadata you have in Dataplex and how many sources sit outside Google Cloud. Automatic cataloging of BigQuery is the easiest part to rebuild, because OpenMetadata has connectors for warehouses, BI tools and pipelines, and it lists more than 130 in total. The harder work is reproducing glossaries, descriptions, aspect types and any custom entries, which usually needs a scripted export and a mapping review. Ask any implementation partner for a written scope that lists the sources, the metadata to carry over and the validation steps before any work starts.
Can a platform team run the OpenMetadata migration without outside help?
A platform team with Kubernetes or Linux operations experience and some data engineering skills can often run a proof of concept alone, using the Docker Compose option for evaluation. Production is a different step, because it needs a hardened deployment, backups, authentication, connector credentials handled securely and a tested upgrade path. Check whether your team has time for those tasks alongside its current workload. DeployOpen implements, hardens, backs up and documents self-hosted platforms in your own infrastructure under a fixed scope, and it can also provide ongoing support as a retainer if your team wants help after go-live.
What skills does a self-hosted OpenMetadata deployment require?
The deployment needs four skill areas: container orchestration, database administration, search administration and Java and Python operations. OpenMetadata documents production deployments on Kubernetes with Helm charts, on Amazon EKS, Azure AKS, Google GKE or on-premises clusters, and on bare metal, which requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Your team also owns backups for the database and search index, monitoring, certificate rotation and access to the ingestion workflows. Confirm these responsibilities with your operations leads before choosing between Kubernetes and bare metal.
How do OpenMetadata 2.0 breaking changes affect an upgrade?
OpenMetadata 2.0 introduced breaking changes that you must plan for before upgrading. The release notes describe 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 have followed about every one to two weeks, with 2.0.0 released on August 24, 2026 and 2.0.5 released on October 8, 2026, so your upgrade calendar needs a regular slot. Read the OpenMetadata 2.0 release notes and test each change in a staging environment before production.
Can we keep BigQuery policy tags when moving off Dataplex?
Policy tags are enforced by BigQuery and Google Cloud IAM, not by the catalog, so they remain in place when you stop using Dataplex for metadata. What changes is where your classification labels are authored and read from. OpenMetadata supports classifications and glossaries, so you can map existing tag names to OpenMetadata classifications and keep the same column-level meaning for users. Confirm the exact mapping with your security team, and test that access in BigQuery still matches your policy after the catalog change.
When does a managed Collate option make more sense than self-hosting?
Collate is the company behind OpenMetadata, and it offers managed OpenMetadata, commercial support and AI features. A managed option makes more sense when your team cannot staff on-call operations for the database, search service and upgrades, or when you need a vendor contract for support. Self-hosting makes more sense when data residency rules, air-gapped networks or lock-in concerns require you to run the platform in your own cloud account or data center. Compare the two by writing down who answers a P1 incident, who applies each release, and where the metadata is stored, then request written terms from Collate for each point.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a Dataplex to OpenMetadata decision, that usually starts with an evaluation scoped to your actual estate: which Google Cloud projects and BigQuery datasets are cataloged today, which sources sit outside Google Cloud, which glossary terms and descriptions are curated by hand, and which lineage or data quality outputs downstream users depend on. Written down, that inventory tells you whether OpenMetadata's connector model and Dataplex's automatic cataloging of Google Cloud resources fit your estate, and what has to be built either way.
Most engagements are fixed-scope. Before work starts, scope, deliverables and timelines are agreed in writing. Typical deliverables for this kind of move include a deployment on your chosen runtime (Kubernetes with Helm charts or bare metal, depending on your standards), connector configuration for each source, a plan for loading glossaries and custom properties, access and single sign-on settings, backup and restore procedures, and documentation your operations team can run without us. Ongoing upgrades, security patching and continuous testing can be covered by a retainer, which matters because OpenMetadata ships maintenance releases frequently. A quote follows from the written scope, so the most useful thing you can bring to a first conversation is the source inventory, your hosting constraints and the people who will own the platform after handover. Confirm with us, in writing, which items are in and out of scope before you compare proposals.
