Who should self-host OpenMetadata and who should buy Collate
The choice between self-hosting OpenMetadata and buying Collate usually turns on three things: where metadata and its lineage may live, what evidence your compliance assessors will ask for, and who on your team can operate the stack. Teams in regulated sectors that must keep metadata inside their own cloud accounts, data centers or air-gapped networks generally fit self-hosted OpenMetadata, because the Apache License 2.0 lets you run the platform yourself without a subscription. That path carries the operating load: you run the database, the search service and the Airflow-based ingestion, and you own patching, backups and high availability. If your organization already has platform engineers who run Java 21, MySQL or PostgreSQL, and Elasticsearch or OpenSearch in production, that load is manageable and the control is worth it.
Collate fits a different profile. Its Premium and Enterprise tiers add SaaS, Hybrid SaaS or, on Enterprise, a private Bring Your Own Cloud deployment in your own VPC, and Collate states it handles installation, upgrades, backups, encryption and high availability. The advertised 99.9% uptime SLA and priority support matter most when nobody on the team can reliably run Java, Elasticsearch or Airflow, or when a metadata outage would stop governed reporting. Before signing, confirm where data is processed under each deployment model, which contractual terms apply to the SLA, and what the user and data asset limits of your chosen tier mean for your estate. Collate's pricing page does not publish prices, so ask for a written quote that covers the tier, the deployment model and any BYOC charges.
Teams that specifically need Collate-only capabilities, such as AI Agents for documentation, data quality and tiering, or the AI Governance Studio currently in release preview, should treat those features as the deciding factor and confirm their maturity and availability with Collate before committing. Collate also states that core metadata, lineage and governance workflows can be migrated back to OpenMetadata at any time, though Collate-exclusive features would not run in the open-source version. Plan for that exit explicitly by documenting your connectors, glossary and access policies now, so a move in either direction is a controlled project rather than a rebuild.
How self-hosted OpenMetadata and Collate differ on the factors that decide it
This table sets self-hosted Apache-2.0 OpenMetadata against Collate's managed tiers on the factors that usually decide the choice. Read each row as a question to answer for your own environment, and treat anything marked as a point to confirm as an item for the Collate quote, not a settled fact.
| Factor | Self-hosted OpenMetadata | Collate |
|---|---|---|
| License and code base | Apache License 2.0; you run the open-source code in your own infrastructure | Collate builds on OpenMetadata and adds Collate-only features; Collate-exclusive features are not in the open-source version |
| Deployment models | Kubernetes (EKS, AKS, GKE or on-premises clusters) or bare metal, plus Docker for trials | Multi-tenant SaaS, single-tenant SaaS, Hybrid SaaS, and Private BYOC in your AWS, GCP or Azure VPC at additional pricing |
| User limits by tier | No user limit set by the license; capacity depends on your sizing and search and database tiers | Free: 5 users. Premium: 25 users. Enterprise: 50 users with unlimited options (Collate pricing page) |
| Data asset limits by tier | No asset limit set by the license; plan storage and search sizing yourself | Free: 500 assets. Premium: 5,000 assets. Enterprise: 10,000 assets (Collate pricing page) |
| Collate-only features | Not included; core metadata, lineage and governance workflows are the open-source scope | AI Analytics, AI Studio, AI Automations, AI Agents for documentation, data quality and tiering, reverse metadata, and data access requests with admin analytics (AI Governance Studio is in release preview) |
| Uptime SLA | None from the project; availability depends on your own architecture and operations | Collate advertises a 99.9% uptime SLA with automated failover (Collate comparison page). Confirm SLA terms and credits in writing |
| Support channels | Community forums and GitHub issues | Priority support from the original creators of OpenMetadata (Collate comparison page). Confirm response targets in the contract |
| Certifications held | Not applicable to the software itself; your evidence depends on your own controls | Collate states it holds SOC 2 Type II, CCPA and GDPR certifications (Collate pricing FAQ). Ask for the current reports and scope |
| Pricing transparency | Software is free; your costs are infrastructure, staff time and any external support | No prices are published on the pricing page; a quote is needed for Premium, Enterprise and BYOC |
| Exit path | Already self-hosted; no migration needed | Collate states core metadata, lineage and governance workflows can move back to OpenMetadata at any time. Confirm export format and timing |
Where your data lives and what compliance evidence you must produce
Collate's three deployment models put your metadata in different places, and each place carries different evidence duties. The cards below cover where data sits, who controls keys and access, what Collate states about its certifications, and what your own environment must still prove.
Data location under SaaS
In multi-tenant and single-tenant Collate SaaS, your metadata is hosted in infrastructure Collate operates, not in your cloud account. Your metadata may include table names, column descriptions, query-derived lineage and sample-based profiling output, so treat it as sensitive even though it is not raw production rows. Ask Collate in writing which regions host your tenant, where backups are kept and which subprocessors touch that data.
Data location under Hybrid SaaS
Hybrid SaaS splits responsibilities, so you must map which components run where and which data crosses the boundary. Confirm with Collate whether connector credentials, ingestion results and search indexes stay in your environment or move to Collate-hosted services. Document that map before procurement, because it defines the scope of your data protection impact assessment and your vendor records.
Data location in your own VPC under BYOC
Private Bring Your Own Cloud runs Collate inside your cloud VPC on AWS, GCP or Azure, which keeps metadata within an account you administer. You still need to confirm who operates the service, who can reach the control plane and whether Collate staff hold administrative access. This model is available at additional pricing, and that cost should be requested as a separate line in the quote.
Access and encryption key control
Ask who holds administrative credentials, database access, search access and the keys used to encrypt data at rest. Collate's pricing FAQ says Collate handles encryption for SaaS customers, which means key custody sits with the vendor unless your contract says otherwise. In a self-hosted OpenMetadata install, your team controls keys, role assignments and audit access directly, and must prove that control to assessors.
Collate's stated certifications
Collate's pricing FAQ states that Collate holds SOC 2 Type II, CCPA and GDPR certifications. Ask for the current SOC 2 Type II report under your NDA, confirm its scope covers the exact service and deployment model you buy, and check the report period. A certification held by the vendor does not transfer to your own controls, so your assessors will still examine how you configure and use the service.
Evidence your environment must produce
Self-hosting moves every control into your scope: access reviews, change records for OpenMetadata upgrades, backup and restore tests, and logging of admin actions. DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. Agree the evidence list with your auditor before the build starts.
How Collate's SaaS, Hybrid SaaS and BYOC models change your control
Collate offers three deployment models, and each one moves a different share of the platform out of your hands. The Free tier runs on multi-tenant SaaS with 5 users and 500 data assets, where the infrastructure is shared with other customers. Premium, with 25 users and 5,000 data assets, runs on single-tenant SaaS or Hybrid SaaS. Enterprise, with 50 users and 10,000 data assets, adds Private BYOC, which runs the platform in your own AWS, GCP or Azure VPC at additional pricing. The model you choose determines whose account, network and region hold your metadata, lineage and sampled data, so settle that question before you compare features.
The core trade is between operational offload and infrastructure location. Collate states that it handles installation, upgrades, backups, encryption and high availability for its customers, and that offload is the main reason teams choose a managed tier. A self-hosted install keeps all of those jobs with your team, including the Java 21 runtime, the MySQL or PostgreSQL metadata store, the Elasticsearch or OpenSearch search tier and the Airflow ingestion layer. Multi-tenant and single-tenant SaaS move that work to Collate but place your data in Collate's environment. BYOC keeps the platform in your cloud account, so confirm which of those five functions Collate still runs there and which fall to your team.
Put these questions to Collate in writing for each model you are considering. Which region and account hold the metadata database, search index and backups? Who holds the encryption keys? How are upgrades scheduled, and can you defer them? How are backups restored and tested, and what does high availability cover during a regional failure? Ask how the stated path back to OpenMetadata would work for your environment, including export formats for lineage, glossary and governance objects, and which Collate-only features would need replacements. Use the Collate pricing page to match each model to your user and asset counts before you request a quote.
What your team runs in each model
This table shows who carries each operating task when you self-host Apache-2.0 OpenMetadata and when you buy Collate. Read the middle column for the work that stays with your team and the right column for what Collate states it handles, then confirm each claim in the written scope or contract.
| Operating task | Self-hosted OpenMetadata | Collate (managed) |
|---|---|---|
| Installation | Your team builds the stack on Kubernetes or bare metal. Bare metal needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. | Collate states it handles installation for customers. Confirm which deployment model (SaaS, Hybrid SaaS or BYOC) fits your data residency rules. |
| Upgrades, including 2.0 breaking changes | Your team plans and tests each release. OpenMetadata 2.0 changed embedding credentials into an llmConfiguration block, required a new Databricks auth format, and needs custom ingestion images rebuilt for Python 3.12. | Collate states it handles upgrades. Ask how Collate tests your connectors and custom images against each 2.0 maintenance release before rollout. |
| Backups and restore testing | Your team backs up the metadata database and search indexes, and tests restores on a schedule you define. | Collate states it handles backups. Confirm backup frequency, retention, restore testing and who can request a restore. |
| Encryption and key management | Your team sets encryption at rest and in transit, and manages keys and certificates for each component. | Collate states it handles encryption. Confirm key ownership, customer-managed key options and where keys live under BYOC. |
| High availability and failover | Your team designs redundancy for the server, database and search tiers, and tests failover. | Collate's comparison page advertises a 99.9% uptime SLA with automated failover. Read the SLA terms, service credits and exclusions before relying on it. |
| Database and search operation | Your team tunes, patches and scales the database and the Elasticsearch or OpenSearch cluster. Minimum sizing for each is 2 vCPUs, 2 GB RAM and 30 GB storage. | Collate operates the database and search services. Ask what it manages, how it scales, and what you still provision. |
| Airflow-based ingestion | Your team runs the ingestion orchestrator, schedules jobs, and fixes failed runs. Metadata ingestion depends on Airflow. | Collate runs the ingestion layer as part of the service. Confirm which connectors run in Collate's environment and which need network access from your systems. |
| Connector maintenance | Your team updates connector credentials, source version changes and ingestion code. OpenMetadata lists more than 130 connectors. | Collate maintains connectors within its service. Ask which connectors are covered, how new source versions are handled, and what you must still configure. |
| Incident response and support | Your team triages failures, relies on community forums and GitHub issues, or buys support from a third party. | Collate's comparison page cites priority support from OpenMetadata's original creators. Confirm response targets and escalation paths in writing. |
Which features exist only in Collate and what you lose by leaving
OpenMetadata is released under the Apache License 2.0 and is maintained by Collate, which also sells commercial capabilities on top of it. The open-source edition carries the core catalog work that most teams start with, and the project's own documentation describes it in these terms. Teams that self-host keep these capabilities without a Collate subscription, subject to the operating work described in the deployment documentation.
- Connectors: OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms.
- Lineage: Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration.
- Data quality: Data quality tests, profiling, freshness checks, glossaries, classifications and domains.
- Programmatic access: REST APIs, a Python SDK, TypeScript packages and Java libraries.
- Release line: The 2.0 line is current, with 2.0.0 released on August 24, 2026 and maintenance releases through 2.0.5.
Confirm with the project's current release notes which of these items your connectors and version require, since the feature list changes between releases.
Collate's comparison page lists a set of additions that it describes as available in Collate and not in the open-source version. Most of them are AI-driven or sit in workflow areas that the open-source edition does not include. The vendor's list is the reference point, so treat it as a list of claims to verify rather than a permanent inventory.
- AI features: AI Analytics, AI Studio and AI Automations.
- AI Agents: Agents for documentation, data quality and tiering.
- AI Governance Studio: Listed as being in release preview, so availability and scope may change before general release.
- Reverse metadata: Pushing catalog metadata back into source systems.
- Access workflows: Data access requests with admin analytics.
Ask Collate which of these are generally available, which are in preview, and whether any depend on a specific deployment model or tier.
Collate states that customers can migrate core metadata, lineage and governance workflows back to OpenMetadata at any time. It also states that Collate-exclusive features would not be available in the open-source version. The practical effect is that a team that adopts Collate-only features should expect to rebuild or drop those features when it returns to self-hosting, while core catalog data is designed to move back.
- Core data: Metadata, lineage and governance workflows are the portion Collate says can move back.
- Exclusive features: Anything built on AI Agents, AI Governance Studio or reverse metadata has no open-source equivalent stated by the vendor.
- Workflow dependence: Access request processes and dashboards built in Collate need to be rebuilt in your own environment.
- Support change: Support moves from the vendor's paid channels back to community forums and GitHub issues.
- Testing: Ask for a written description of the export path and run a test migration with a non-production dataset.
Confirm the exact migration steps, data formats and any unsupported objects in writing before committing to Collate-only workflows.
This comparison reflects the vendor's published comparison page at the time of research. Vendor feature lists, release preview status and tier contents change, and a list copied into a procurement file can go out of date quickly. The reader should treat the points on this page as a starting checklist and verify each one against the live source before a decision.
- Source of truth: Collate's comparison page is the authoritative list of what it says is exclusive.
- Release status: Preview features can move to general availability or change scope between releases.
- Open-source changes: OpenMetadata moves quickly, so check the release history for features added to the open-source edition.
- Written confirmation: Ask the vendor to confirm exclusive features, tier limits and migration terms in the contract or order documentation.
- Independent check: Ask an implementation partner to test the features you depend on in your own environment.
Date-stamp any comparison you circulate internally and set a review date before the next renewal.
How to move between self-hosted OpenMetadata and Collate
This sequence shows how a team confirms that its asset and user counts fit a Collate tier, or that it can leave Collate for a self-hosted OpenMetadata install, without losing metadata, lineage, governance workflows or user access. Each step ends with a check you can record before moving on.
Measure your current asset and user counts
Start by counting the users who log in and the data assets your catalog holds, including tables, dashboards, pipelines and other entities that would count toward a tier. Your platform team or catalog administrator does this against the live environment, not against the sizes you planned. Record the totals and the date of the count. You are done when you have a single signed-off number for users and one for data assets, which you can compare against the limits on Collate's pricing page: Free at 5 users and 500 data assets, Premium at 25 users and 5,000 data assets, and Enterprise at 50 users and 10,000 data assets. Ask Collate in writing how it counts assets so the comparison is like for like.
Compare limits and deployment models against the tier
Map your counts to a tier and then to a deployment model. Collate's pricing page places multi-tenant SaaS on Free, single-tenant SaaS and Hybrid SaaS on Premium, and Private BYOC on Enterprise, where the customer's cloud VPC is used on AWS, GCP or Azure at additional pricing. Note whether your data residency, network or air-gap rules require a model that keeps data in your own accounts. Your security lead signs off on the chosen model. You are done when you have a written tier and deployment model that fit both counts and your hosting constraints, or a documented reason to stay on self-hosted OpenMetadata.
Confirm the migration scope in writing
Collate states that customers can migrate core metadata, lineage and governance workflows back to OpenMetadata at any time. Treat that as a starting claim, not a contract. Ask Collate to list in writing which objects move (entities, lineage, glossaries, classifications, domains, data quality test definitions, users and roles), which do not, and who performs the export and import. Request any fees for the migration itself in the same document, along with what Collate needs from you and the support window. Your procurement and legal teams review the reply. You are done when the scope, exclusions and fees are in a signed or dated document that names the objects to be moved.
Inventory Collate-only features that will not carry over
Collate's comparison page lists Collate-only additions such as AI Analytics, AI Studio, AI Automations, AI Agents for documentation, data quality and tiering, AI Governance Studio (in release preview), reverse metadata, and data access requests with admin analytics. Collate also states that these exclusive features would not be available in the open-source version. List which of these your teams use today, and which workflows depend on them, such as access request approvals or automated documentation. For each one, decide whether to rebuild it, drop it, or keep the workflow in Collate. Your data governance owner signs off. You are done when every Collate-only feature in use has a written decision and an owner.
Plan ingestion job and connector re-pointing
Ingestion jobs and connector settings point at a specific server, so they must be re-pointed when the catalog moves. List every connector your team runs, including warehouse, BI, pipeline and ML sources. For self-hosted OpenMetadata, confirm the ingestion orchestrator and its versions against the bare metal requirements (Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow). Check the 2.0 breaking changes, including the llmConfiguration block for embedding credentials and the new Databricks auth format, before you re-point jobs. Your data platform engineers own this list. You are done when each connector has a target, a credential owner and a test run scheduled against the new server.
Validate search, lineage and user access
Once the metadata is in the target environment, run a set of checks that mirror real use. Search a sample of known assets and confirm that results, owners, tags and glossary terms match the source. Trace table, column, dashboard and pipeline lineage for a handful of critical datasets. Log in as one user from each role and confirm that permissions, SSO and group membership behave as before. Your catalog administrator runs the checks and the owners of the sampled assets confirm the results. You are done when the test log shows no unexplained gaps and each sampled user can see what they could see before the move.
Cut over and retain the source record
Schedule the cutover window with the teams that rely on the catalog, and announce the new URL and login path in advance. Freeze ingestion on the source, run a final sync, and point users and jobs at the target. Keep the source environment or an export of it for a period your records and compliance owner set, so you can answer questions about metadata that existed before the move. Your platform lead approves the cutover and the retention period. You are done when the target is the only system receiving ingestion, the retained source is documented, and the cutover record is filed with the migration scope from step three.
Questions buyers ask before choosing Collate or self-hosting
What drives the cost of Collate compared with self-hosting OpenMetadata?
Collate is a subscription that covers the platform, installation, upgrades, backups, encryption and high availability, so the recurring fee replaces much of the infrastructure and operations work you would otherwise carry. Collate's pricing page publishes tier limits (users and data assets) but no prices, so the fee depends on tier, deployment model and any private BYOC add-on. Self-hosting shifts cost to cloud or data center resources for the Java service, database, search cluster and Airflow ingestion, plus the staff time to run them. Ask Collate for a written quote that states the tier, user and asset counts, deployment model, support level and whether BYOC pricing applies. For your own side, model the infrastructure bill and the engineer hours for upgrades, backups and on-call, since those recur every year.
How long does a self-hosted OpenMetadata production install take, and how much effort does it need?
The timeline depends on your environment, prior Kubernetes or bare metal experience and how many connectors you need, so treat any single duration with caution. The supplied sizing sets the floor: OpenMetadata's minimum server needs 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, per the bare metal deployment documentation. Production also requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and an Airflow environment for ingestion. Effort goes into those dependencies, TLS, authentication, backups, upgrades and connector configuration. Ask your team to map each dependency to an owner before committing to a date.
Can a small team self-host OpenMetadata without a partner?
A small team can run it without a partner if it already operates a database, a search cluster and Airflow, and has someone comfortable with Kubernetes or Linux server administration. The risk is concentrated in upgrades: 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. Maintenance releases have followed about every one to two weeks, so someone must own the upgrade calendar. If no one on the team can absorb that, a managed option or an independent implementation partner for a fixed scope is worth comparing.
What does the 99.9% uptime SLA cover, and what does it leave out?
Collate's comparison page advertises a 99.9% uptime SLA with automated failover and priority support for its managed service. It describes availability of the service Collate operates, not the quality of your metadata, the correctness of your connector configuration or the timeliness of your ingestion runs. Read the contract for how uptime is measured, what counts as downtime, the service credits or remedies offered, exclusions for scheduled maintenance and customer-caused issues, and who handles incident communication. Self-hosted users have no contractual SLA from the maintainers and instead rely on community forums and GitHub issues, so the equivalent availability target must be met by your own monitoring and on-call design.
Can data leave Collate, and how does migration back to OpenMetadata work?
Collate states that customers can migrate core metadata, lineage and governance workflows back to OpenMetadata at any time, and that Collate-exclusive features would not be available in the open-source version. Before relying on that, confirm in writing the export format, whether lineage history, glossary terms, tests and permissions move with the export, what happens to ingestion pipelines and connector credentials, and how long the export remains available after cancellation. Plan a dry run against a non-production instance, since AI features and any Collate-only objects will need a substitute or will be dropped. Keep your own copy of connector configurations so a move back does not depend on the vendor.
Does Collate hold SOC 2 Type II, and what does that mean for our audit?
Collate's pricing FAQ states that Collate holds SOC 2 Type II, CCPA and GDPR certifications. A SOC 2 Type II report is an attestation issued by an independent auditor covering controls over a period, so ask Collate for the current report under NDA and check its scope, the trust services criteria covered, the subservice providers and any exceptions. Self-hosting means these controls become your own: your auditor will want evidence for access, change management, backups and encryption across the database, search and ingestion layers. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations.
Can DeployOpen help with either path, and how is that scoped?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a self-hosted OpenMetadata path, that can cover architecture, dependency setup, security hardening, connector integration, backup and upgrade runbooks, and documentation. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not run Collate's managed service, and it does not publish a price list, so a quote follows from the written scope you agree.
How DeployOpen plans and supports self-hosted OpenMetadata
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a decision between Collate and self-hosted OpenMetadata, we start by writing down what your team needs to run, who will operate it and where the data must stay.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists the connectors, databases, search service and ingestion orchestrator your environment needs.
- We confirm which OpenMetadata 2.0 breaking changes apply to your existing connectors and custom ingestion images.
- Quotes follow from the written scope, so we ask you to state data sources, user counts and hosting constraints first.
How we build
- We deploy OpenMetadata on the target platform you choose, such as Kubernetes or bare metal, inside your own infrastructure.
- We configure the database, search service, ingestion orchestrator and SSO integration against your identity setup.
- We test lineage ingestion, data quality tests and access controls against a defined set of representative sources.
- We document configuration, prerequisites and version pins so your platform team can reproduce the build.
How we hand over
- Handover includes runbooks for backups, upgrades, restores and ingestion job troubleshooting in your environment.
- We prepare the migration plan and cutover checklist if you move from another catalog or from a Collate trial.
- We document the controls and evidence that your auditors or assessors may ask to see for the catalog.
- Your team receives training scoped in the written agreement, so operators can run the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover maintenance releases, such as the 2.0.x line, with testing before changes reach production.
- Ask any provider which parts of uptime, failover and priority response are contractual and which are best effort.
- Your team keeps ownership of the data and the environment, and we confirm responsibilities in writing before work starts.
