What OpenMetadata cost of ownership covers once the Apache 2.0 license is free
OpenMetadata is released under the Apache License 2.0, so the software itself carries no license fee. The recurring cost sits in the infrastructure that runs it, the database and search services it depends on, the ingestion work that keeps metadata current, the upgrades that keep the platform supported, and the people who keep ownership, definitions and quality checks accurate. A team comparing a self-hosted catalog with a commercial one should model those five lines first. Collate, which maintains OpenMetadata, sells commercial enterprise capabilities and premium support, so the comparison should be made against a written list of what each option includes.
Start with the platform's stated prerequisites. Bare metal deployments need Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The documented minimum server 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. Those figures are minimums, not production sizing. Production capacity depends on asset count, profiling volume and concurrent users, so have your platform team or implementation partner size from your own catalog and load test before committing hardware or cloud reservations. Managed database and search services shift the cost toward metered service fees, so price both self-run and managed options.
Ingestion is the largest variable cost after infrastructure. OpenMetadata lists more than 130 connectors, and each one adds scheduled jobs, credentials to rotate, a service account to govern and a regression to test after upgrades. Profiling and data quality tests run queries against your warehouses, so part of their cost lands on your warehouse bill. Upgrades are recurring work as well: maintenance releases arrive about every one to two weeks, and the 2.0.0 release, published August 24, 2026, brought breaking changes including moved embedding credentials, a new Databricks auth format, Python 3.12 rebuilds of custom ingestion images and a Great Expectations 1.3 migration before upgrading. Budget engineering time for each cycle, not only for the initial install.
People are usually the largest recurring cost and the easiest to underestimate. Someone must own domains, approve glossary terms, assign owners to tables and dashboards, review failing quality tests and close lineage gaps that automated extraction misses. Ask who in your organization holds each of those roles and how many hours a month each person can spare, and check whether the same people also run the platform. Keep a separate line for on-call coverage of the ingestion scheduler and the database. If you consider Collate's commercial offering, confirm in writing which enterprise capabilities and support levels it includes, which features remain in the open source release, and how upgrade timing is handled for your installation.
Many teams model and run this cost in-house at first, because the license is free and the infrastructure lines are familiar. Others bring in a partner for the parts that are harder to estimate: the cost model itself, sizing against actual catalog volume, the choice between self-hosting and Collate's commercial offering, and support during upgrades. DeployOpen does not publish a price list. A quote follows from a written scope that names the deployment target, connector count, database and search choices, and the support model you want, so the figures in your comparison should come from that document and from your own environment.
What a cost of ownership engagement includes and delivers
Each card is a deliverable in a cost of ownership engagement, and together they show what OpenMetadata will cost to run and who will run it. Some items are working files you keep after handover. Others depend on confirmation from OpenMetadata, Collate or your cloud provider, and the cards mark which is which.
Server, database and search sizing model
The sizing model sets tiers for the OpenMetadata server, the MySQL or PostgreSQL database and the Elasticsearch or OpenSearch service. The bare metal deployment documentation lists minimums of 2 vCPUs, 4 GB RAM and 20 GB storage for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage for each of the database and search services. Treat these as floors, not production sizing. You own the sizing notes after handover. Confirm growth assumptions for your asset count and ingestion volume with OpenMetadata or Collate before you commit to a tier.
Connector and source inventory
The inventory lists every warehouse, BI tool, pipeline and ML platform you plan to connect, with the connector name, the ingestion schedule, the credential type and the network path from the ingestion runner to each source. OpenMetadata lists more than 130 connectors, but a listed connector does not confirm support for your exact source version. Sources without a matching connector need custom work, which the inventory should flag early. You keep the inventory after handover. Confirm connector version support for your sources against the OpenMetadata release you plan to run.
Recurring cost model and assumptions
The cost model separates one-time setup from recurring spend: server, database and search hosting, ingestion compute, backup storage, and warehouse query cost driven by profiling and sampling. Each line records its assumption, such as instance size, schedule frequency or sampling method, and the person who owns that assumption. Changing an assumption updates the forecast, so the model stays useful after handover. You own the spreadsheet. Cloud and warehouse prices come from your providers' current price sheets, so confirm those figures directly with them.
Edition comparison against your requirements
OpenMetadata is released under the Apache License 2.0 and maintained by Collate, which also offers commercial enterprise capabilities and premium support. The comparison starts from the capabilities you need, such as SSO, lineage depth, data quality operations, audit needs and support response expectations, then records how the self-hosted project and Collate's offering each address them. Collate must confirm current edition contents, terms and support commitments in writing, and the comparison marks any row that rests on those confirmations as pending until they arrive.
Steward workload estimate by role
The workload estimate sets out the recurring effort for each role: platform administrators who run upgrades and backups, data stewards who maintain glossary terms and ownership, domain owners who review lineage and quality failures, and data engineers who maintain connectors and custom ingestion images. Each role is tied to specific tasks such as reviewing intake forms or triaging failed tests. Effort figures are estimates that a pilot should validate. You keep the workload table after handover and update it as domains and sources grow.
Upgrade and support obligations
This list records who performs each upgrade and support task and on what schedule. OpenMetadata 2.0.0 was released on August 24, 2026, with maintenance releases 2.0.1 to 2.0.5 following about every one to two weeks. The 2.0 breaking changes include 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. Confirm patch cadence and support terms with OpenMetadata or Collate for your edition.
Which factors push OpenMetadata running costs up or down
This table lists the main drivers of OpenMetadata running costs, why each one moves spend, and one way to keep it down. Read each row against your own source count, warehouse setup and environment plan. The main takeaway is that connector count, profiling scope and environment count compound, so scoping them early keeps the footprint predictable.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Number of connectors | OpenMetadata lists more than 130 connectors, and each one you onboard adds ingestion jobs, credentials and failure handling to run. | Onboard sources that feed governed domains first, and retire unused ingestion pipelines on a schedule. |
| Data volume and profiling scope | Profiling and tests read warehouse data, so wider table coverage raises query load and compute on your sources. | Scope profiling to priority tables, and confirm the sampling settings in your deployment before enabling it broadly. |
| Dynamic Sampling (2.0 default) | Dynamic Sampling became the profiler default in 2.0, which changes how many rows each profiling run reads from the warehouse. | Review the default sampling behavior against your warehouse query costs before running profiles on large tables. |
| Search cluster sizing | Elasticsearch 9.x or OpenSearch 3.x holds the metadata index, which grows with assets, lineage and search traffic. | Start from the documented minimum for the search service, then size from measured index growth and query load. |
| Database choice | MySQL 8.0.42 or later or PostgreSQL 15 or later stores all metadata, and a managed instance adds a recurring service fee. | Use the engine your team already operates, and confirm the version floor before provisioning. |
| Number of environments | Each environment, such as development, test and production, repeats the server, database, search and ingestion footprint. | Keep non-production environments smaller, and run ingestion there against a reduced connector set. |
| SSO and high availability | SSO and multiple server replicas add identity setup and running capacity, and SSO cannot be combined with basic authentication. | Confirm the replica and scheduler design your Kubernetes platform needs before adding redundancy to every environment. |
| 2.0 upgrade path | Release 2.0.0 changed defaults and required rebuilds, including Python 3.12 ingestion images and Great Expectations 1.3 migration. | Test upgrades against your custom ingestion images and connectors in a non-production environment before cutover. |
| Edition chosen | The Apache 2.0 code is free to use, while Collate's commercial enterprise capabilities and premium support are a separate decision. | Ask Collate to state in writing which enterprise capabilities and support terms you would actually need. |
Apache 2.0 self-hosting versus Collate's commercial offering
OpenMetadata is released under the Apache License 2.0 and is maintained by Collate, which also sells commercial enterprise capabilities and premium support. The first cost decision is therefore not whether the software is free to use, but whether your team will run it on the open-source release alone or buy part of its operation from the company that builds it. This page does not state what each tier includes, what it costs or what terms apply, so obtain those in writing from Collate before you finalize any budget or compare totals.
Ask Collate for a current, itemized list of the capabilities included in each tier and confirm which of them you would depend on. Request the commercial terms in the same document: the license model, how pricing is calculated (for example by user, by asset, by environment or by year), what is one-time and what recurs, and whether the price changes with the number of connectors or ingestion volume. Also ask whether any feature you need is available only in a paid tier, and whether that answer applies to the release line you plan to run, since the 2.0 line changed several areas at once.
Three questions usually decide the choice. First, does your organization need vendor support with defined response commitments, or can your platform team absorb incidents and upgrade problems itself? Second, which enterprise features matter to your governance model, such as the access, workflow or administration capabilities your stewards and auditors expect? Third, how much internal engineering time can you staff for upgrades, custom ingestion image rebuilds, connector regression testing and backup verification over the life of the platform. Write down an answer to each before comparing offers, because the answers change which costs you carry internally.
Self-hosting under Apache 2.0 still has recurring costs: the infrastructure for the server, database, search service and ingestion scheduler, the engineers who upgrade and patch them, and the data stewards who keep domains, glossary terms and ownership current. Commercial support shifts part of the engineering and response burden, but it adds subscription fees and may not remove internal ownership. Model both paths with the same assumptions for hosting, staffing and connector count so the difference reflects the support model rather than inconsistent inputs.
DeployOpen is not a Collate partner or reseller unless that status is confirmed separately in writing, and this page makes no such claim. DeployOpen can build a cost comparison that models both the self-supported path and the commercial path, using the written Collate terms you obtain and your own hosting, staffing and connector figures. Where a number is missing from those sources, the comparison will show it as an open item for you to confirm rather than an estimate.
How a cost of ownership model is built, step by step
This sequence turns an OpenMetadata deployment plan into a cost of ownership model that finance and platform leaders can review. Each phase produces a named output, so every line in the model traces back to the source inventory, sizing decisions and workload assumptions behind it.
Discover sources, connectors and users
Your team and DeployOpen list every data source the catalog must cover, including warehouses, BI tools, pipelines and ML platforms. Match each source to OpenMetadata's connector catalog, which lists more than 130 connectors, and confirm any source that is not on the published list with the maintainers before counting it. For each source, record the access method, the expected ingestion frequency and the teams that will use the output. Count named users and expected viewers as well, because a commercial agreement may price by user. The output is a source and user inventory signed off by the data platform owner.
Map stewards and ownership roles
Identify who owns each domain, who maintains glossary terms and classifications, and who responds to data quality alerts. Interview domain leads and record how much time each role will spend on catalog work each month, using the ownership model your governance program already defines. The output is a roster that names every steward role, its scope and its escalation path. This roster is the input for the workload model in a later step. Avoid assuming every owner is a full-time role. Confirm with each domain lead how much of their week the catalog will take.
Size server, database and search tiers
Start from the published bare metal minimums: the OpenMetadata server at 2 vCPUs, 4 GB RAM and 20 GB storage, and the database and search services each at a minimum of 2 vCPUs, 2 GB RAM and 30 GB storage. Treat these as floors. Production sizing rises with source count, profiling scope, query log volume, concurrent users and the retention period you set for ingestion history. Prerequisites add Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The output is a tier table with vCPU, memory and storage for each component in each environment, mapped to the cloud or data center line items that will carry them.
Compare editions and support options
Place the self-hosted Apache 2.0 build beside the commercial offering from Collate, which maintains the project and also provides enterprise capabilities and premium support. For each option, list the features your use cases depend on, the support response model, the upgrade assistance included and who carries patching and on-call duties. Request written feature and support terms from Collate, and confirm which capabilities exist in the open-source build before you rely on them. The output is a comparison matrix with a cost line for each option, where each figure is marked as quoted or internal, and vendor licensing terms are recorded as stated by the vendor.
Model steward and operations workload
Convert the roster and inventory into hours. For each connector group, estimate onboarding effort, recurring ingestion failure triage and the upgrade work that follows each OpenMetadata release, including breaking-change review and rebuilds of custom ingestion images. Add steward time for glossary upkeep, lineage gap filling and routing data quality alerts to owners. Label each estimate with its basis, such as your team's past effort, a scoped DeployOpen estimate or a vendor figure. The output is a workload model showing hours per role per month, with each task marked as one-time or recurring.
Build the recurring cost model
Combine infrastructure, subscription or support terms, implementation and labor into one model. Separate one-time costs, such as initial deployment, connector onboarding and integration, from recurring costs, such as cloud compute, storage, database and search services, support and steward time. Run sensitivities on the drivers that move the total most: source count, profiling and sampling scope, query log volume, retention and user or viewer counts. The output is a model with named assumptions, a base case, several sensitivity cases and an owner for each assumption. Ask every vendor and partner to state the assumptions their quote depends on.
Run the handover review
Walk through the model with finance, the platform owner, security and the stewards who will carry the work. Confirm that every assumption has a named owner and a date for re-checking, and that the model reflects the release line you intend to run. Check the tier sizing against the production load you expect, the edition choice against the features in scope and the workload figures against the roster. The output is a signed-off model, a list of open questions with owners and a refresh plan for quotes and vendor terms. Keep the model under version control so each change can be traced to its source.
Which recurring costs continue after go-live
This table lists the costs that keep arriving after OpenMetadata goes live, marking each as fixed or variable and naming what to confirm with your cloud or data center team. Apache 2.0 removes a software license fee, so the run budget is mostly infrastructure, ingestion, upgrade effort and people. The main takeaway is that these lines recur together, so request every one of them in the same quote.
| Cost line | Fixed or variable | What drives it | What to request to confirm |
|---|---|---|---|
| Server compute for OpenMetadata | Fixed | Replica count, JVM memory, user and API traffic | Instance type, replica count, reserved or on-demand rate, and autoscaling rules |
| Relational database hosting | Fixed | MySQL 8.0.42 or later or PostgreSQL 15 or later, instance class, standby and storage | Managed instance class, standby or multi-zone charges, and backup retention fees |
| Search cluster hosting (Elasticsearch 9.x or OpenSearch 3.x) | Fixed | Node count, memory per node, shard count and index growth as metadata expands | Node count, storage per node, and whether billing is per node or per domain |
| Ingestion compute and scheduling | Variable | Number of connectors, run frequency, Airflow 3.3.0 workers and profiling jobs | Worker sizing, schedule per connector, and the monthly compute bill for the ingestion pool |
| Warehouse query cost from profiling and freshness checks | Variable | Sampling settings (Dynamic Sampling is the 2.0 default), table count and check frequency | Query spend by the OpenMetadata service account and the sampling configuration in use |
| Storage growth and backups | Variable | Metadata history, lineage events, logs and retention periods | Current storage size, monthly growth, backup retention period and snapshot storage cost |
| Upgrade and patch effort | Variable per release | Maintenance releases 2.0.1 to 2.0.5 arrived about every one to two weeks; 2.0 has breaking changes | Staff hours per release, staging availability and regression test coverage |
| Custom ingestion image rebuilds for Python 3.12 | Variable | Each custom connector image must be rebuilt and retested for Python 3.12 | Rebuild frequency per custom image, registry storage and CI runner minutes |
| Commercial support, retainer or internal skills | Fixed when contracted | Collate offers premium support; stewards and platform engineers maintain the stack | Collate's written support terms and fees; steward and platform headcount in the budget |
How the cost picture changes by deployment target and starting point
OpenMetadata documents production deployments on Kubernetes, including AWS EKS, Azure AKS, Google GKE and on-premises clusters. Most of the cost sits in the platform around the application: node capacity, the database, the search service and the people who operate them. If your platform team already runs a cluster, the incremental infrastructure cost depends mainly on spare capacity and existing operational tooling.
- Compute nodes: The server, ingestion and search workloads draw on existing node pools. Confirm whether the cluster has headroom or whether new node groups must be provisioned and tuned.
- Managed database and search: Choose between a cloud-managed MySQL or PostgreSQL service and a self-run database, and between managed search and self-run Elasticsearch or OpenSearch. Managed services add a recurring line but reduce on-call effort.
- Ingestion images: Ingestion runs on Apache Airflow, so custom connector images must be built and stored in your registry. Each OpenMetadata upgrade may require rebuilding them.
- Storage and network: Persistent volumes, snapshots and cross-zone traffic recur monthly and vary by cloud account and region.
- Platform team time: Release upgrades, certificate rotation and cluster version changes are recurring work, either for your staff or under a support retainer.
Before quoting, confirm which managed database and search services your cloud account supports, who owns the cluster upgrade calendar, and whether the cluster must sit in a particular region.
Bare metal without Kubernetes means installing the OpenMetadata server, database and search service directly on hosts, then managing process supervision, patching and backups yourself. The project's bare metal prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The documented minimum server sizing 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. These are floors, and production capacity depends on the number of sources and the query load.
- Host count: Running the server, database and search on separate hosts is a common design choice. It raises host count, and it may raise operating system licensing if your OS is commercial.
- Software lifecycle: Java, the database and the search service must each be tracked against OpenMetadata release notes, which adds recurring patch work.
- Restarts, backups and restores: Without an orchestrator, you build service restarts, scheduled backups of the database and search indexes, and regular restore tests.
- Ingestion placement: Ingestion workers need their own host or container runtime and network paths to sources. Plan them separately from the server.
- Hosting model: Owned hardware carries a one-time purchase and recurring data center costs. Rented servers recur monthly.
Before comparing this with a Kubernetes estimate, confirm the host count for each role, the operating system support window, and who performs restores and how often they are tested.
Docker is documented for local trials, and it is not the production model. It lets a team test connectors, lineage views and glossary workflows quickly. Its cost is mostly a developer machine or shared sandbox virtual machine and the engineering time spent exploring. The cost that matters is what the trial leaves behind for the production design.
- Hardware: Size a developer machine or sandbox VM to run the server, database and search together. Check memory headroom against the documented minimums before starting.
- Source data: Use sampled or synthetic data where possible. Connecting production sources to a trial instance copies real metadata and credentials into a less controlled environment.
- Trial effort: Exploration time is one-time and is easy to underestimate, especially when stakeholders request connector demonstrations.
- Carryover: Configuration, custom connectors and glossary content built in Docker rarely move unchanged into a production model. Budget for rebuilding them.
- Licensing: The open-source code is licensed under Apache 2.0, so the trial adds no license line. Confirm the terms for any Collate commercial features you evaluate.
Before the trial starts, decide which findings will feed the production design, and list the cost lines the trial does not test, such as high availability for the database, backup and restore, and SSO.
In an air-gapped network, the cost moves from downloading software to transferring, verifying and installing it. Container images, packages and connector dependencies must be mirrored into internal registries and repositories, and every upgrade repeats that cycle offline. The effort compounds with the number of connectors you enable, because each one adds dependencies to stage and test.
- Image mirroring: Mirror the server, database, search and ingestion images, along with any custom ingestion images you rebuild. Each release needs a new mirror pass.
- Dependency staging: Connector libraries and Python packages must be retrieved, scanned and staged for offline installation.
- Offline upgrades: Review release notes and breaking changes before media enters the enclave. The 2.0 release, for example, requires rebuilding custom ingestion images for Python 3.12 and migrating Great Expectations to 1.3 before upgrading.
- Transfer approvals: Cross-domain transfer approvals and change windows add elapsed time and recurring staff effort.
- Support channels: Confirm how patches and support are delivered inside the enclave, and whether the retainer scope covers offline delivery.
Before estimating, ask who approves each transfer, how long a full mirror cycle takes in your environment, and whether the connector inventory should be reduced to what the enclave can reach.
Moving from a commercial catalog produces license savings only after migration, parallel running and retraining are counted. The renewal you avoid is one line. The one-time migration work, the overlap period and the change in how stewards and owners work are the lines that decide the first year. OpenMetadata is maintained by Collate, which also offers commercial enterprise capabilities and premium support, so the comparison should include that option if you want it.
- License comparison: Set the commercial renewal against OpenMetadata infrastructure, staffing and any Collate agreement you choose. Ask the current vendor for the renewal terms in writing.
- Migration work: Export glossary terms, ownership, lineage, classifications and custom fields, then map and validate them in OpenMetadata. This cost is one-time.
- Parallel running: Keeping both catalogs live for a period duplicates some recurring costs and staff time. Agree the overlap length with stakeholders before the cutover date is set.
- Integrations: Downstream tools that call the old catalog must be rewired to OpenMetadata REST APIs or SDKs, which adds development and testing effort.
- Adoption: Stewards and owners need training on new workflows, and governance meetings recur after cutover.
Before setting a budget, confirm the commercial contract end date, the export rights your current vendor grants, and the criteria that will allow the old catalog to be switched off.
Where OpenMetadata cost models usually go wrong
Most OpenMetadata cost estimates fail in the same few places: undersized infrastructure, unbudgeted warehouse query and steward time, and upgrades treated as optional. Each card names one error and the check that prevents it. Work through them before you compare the open-source edition with Collate's commercial offering.
Sizing from published minimums
The published minimums describe a server with 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. These figures describe a working install, so treat them as a floor. Size from your expected table counts, profiling scope, ingestion frequency and concurrent users, then load test a staging copy before you commit to node counts and storage growth.
Ignoring warehouse query cost
Profiling, data quality tests and freshness checks send queries to your warehouse, and most warehouse platforms bill for that compute. Dynamic Sampling became the profiler default in OpenMetadata 2.0, which changes how much data each run reads, so confirm the profiler settings for every database service. Ask your warehouse team to estimate query spend per schedule before you enable checks across all tables.
Underestimating steward time
Ownership, glossary terms and classifications stay accurate only when someone reviews them over time. Model steward effort as a recurring cost covering new tables surfaced by each connector run, glossary change approvals and retirement of stale definitions. Confirm which person owns each domain, how much of their time that role is expected to take, and whether the rollout budget funds that time after launch.
Leaving upgrade effort out
OpenMetadata 2.0 carried breaking changes, including embedding credentials moved into an llmConfiguration block, a new Databricks auth format, custom ingestion images rebuilt for Python 3.12 and Great Expectations migrated to 1.3 before upgrading. Maintenance releases 2.0.1 to 2.0.5 followed about every one to two weeks. Include recurring upgrade, regression testing and image rebuild effort in the model, not only the initial deployment.
Planning access around SSO and basic auth
OpenMetadata does not support using multiple authentication mechanisms at once, such as combining SSO and basic authentication. Decide early which identity method will serve all users, and plan how administrator, bot and recovery access will work under that single method. Confirm with your identity team how locked-out accounts will be recovered before cutover, because this choice affects support effort and access planning.
Treating license comparison as total cost
Apache License 2.0 removes a license fee for the open-source edition, but infrastructure, stewardship, upgrades and support still carry cost. Collate maintains OpenMetadata and offers commercial enterprise capabilities and premium support, so compare its scope against the features and support levels your team needs. Build the model from every recurring component first, then add commercial edition terms only after you receive a written quote.
What the client needs to provide for an accurate cost model
An accurate cost model depends on inputs that only the client can supply. Before a partner can estimate what OpenMetadata costs to run, the team needs current cloud or data center pricing for the compute, storage and network it will use, along with the reservation or commitment terms that apply to each. Ask finance and the cloud account owner for actual invoices from the last three to six months rather than list prices, because discounts, committed-use agreements and existing enterprise terms change the result substantially. Note which of these costs already sit in a budget and which would be new.
The second group of inputs describes how much metadata OpenMetadata will carry and how hard it will work. List the expected number of sources and connectors by type: warehouses, BI tools, pipeline orchestrators and ML platforms. Estimate warehouse query volumes, since profiling, sampling and data quality tests all run queries against the client's own warehouse and that load is billed by the warehouse vendor. Document the profiling plan too, including which schemas will be profiled, how often, and whether sampling is expected to be the default. Each of these choices moves ingestion frequency, database write volume and search index size.
People drive a large share of the ongoing cost, so the cost model needs a roster. List the teams that will publish metadata, the domains they own, and the steward roles expected for each: who approves glossary terms, who owns data quality failures and who maintains classifications. Estimate how many hours per week each steward role will realistically spend, and confirm whether those roles already exist or must be staffed. Decide who will run the platform itself, because on-call coverage for the database, search cluster and ingestion scheduler is a separate line item from stewardship.
Several structural choices change the bill and must be settled before quoting. Name the target deployment platform (Kubernetes on a managed cluster, or bare metal), the identity provider that will handle single sign-on, and the environments required, such as development, staging and production, each with its own database and search service. State retention and backup expectations for the metadata store and the search index, including how many restore points and how long the client's policy requires. Confirm whether the client expects the platform to be upgraded and tested in a non-production environment first, since that doubles some infrastructure.
Finally, name one decision owner for the edition choice. Between the Apache License 2.0 release and Collate's commercial offering, the difference lies in enterprise capabilities and support terms, and only Collate can state what those terms include, what they cost and how they renew. The decision owner should request those terms in writing from Collate and, where the organization buys software through procurement, have the legal or procurement team confirm them before the model is finalized. Any figure taken from a verbal conversation should be treated as provisional until it appears in a signed quote.
Questions buyers ask about OpenMetadata cost and editions
Is OpenMetadata free to self-host compared with the commercial tier?
The OpenMetadata project is released under the Apache License 2.0, so the software itself carries no license fee for self-hosting. Collate, which maintains the project, also offers commercial enterprise capabilities and premium support. Compare the two by listing the features and support levels you need, then asking Collate for its current commercial terms in writing. Your self-hosted cost is the infrastructure, the people who run it, and any outside help you buy, so the decision usually turns on whether you need the commercial capabilities or premium support rather than on the software price.
What drives the recurring cost of running OpenMetadata?
The recurring bill is mostly infrastructure and people. The published minimum server sizing 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. Production sizing rises with the number of connectors, the volume of metadata, profiling frequency and user count. Other recurring items include:
- Database: MySQL 8.0.42 or later, or PostgreSQL 15 or later, on a managed or self-run service
- Search: Elasticsearch 9.x or OpenSearch 3.x, sized for index growth
- Ingestion: scheduler capacity and warehouse query cost from profiling and tests
- Steward time: people who maintain ownership, glossary and quality rules
Confirm each line against your own cloud pricing and volumes.
How long does it take to produce an OpenMetadata cost model?
The time depends on how many inputs you can supply quickly. A cost model needs your deployment target, the number of sources and connectors to onboard, expected metadata volume, profiling and data quality scope, required authentication and high availability level, and the steward model you plan to run. If those are settled, the model can be built from a written scope. If they are not, the first step is a scoping session that settles them. Ask any provider for the timeline in writing, with the inputs it needs from your team and the steps that depend on each input.
What does the work need from our team to build a cost model?
Expect to supply people who know your data estate and your infrastructure. Typically this means a platform or cloud owner who can share sizing targets and networking constraints, a data platform lead who can list the warehouses, BI tools, pipelines and ML platforms in scope, and a security contact who can confirm identity and credential rules. Stewards or data owners should estimate how many domains and glossary terms they expect to maintain. Ask the provider to name each input, who owns it and the date it is needed, so the model does not stall on missing answers.
Can our own engineers build an OpenMetadata cost model without a partner?
Yes, a capable internal team can build a cost model, because the sizing inputs are public and the software is open source. The main work is measuring your own source counts, metadata volume and query patterns, then testing the deployment in a trial environment before committing to sizing. Where internal teams usually struggle is in estimating profiler and data quality query cost against warehouse pricing, and in planning steward time. Decide early whether you want the model built internally, with an outside review, or fully outsourced, and confirm which parts of the work each option covers.
What does a fixed-scope quote for OpenMetadata cover?
A fixed-scope quote covers the work described in a written scope before the engagement starts. For a cost model, that usually includes the inputs reviewed, the deployment assumptions, the sizing approach, the infrastructure and recurring cost components, the assumptions behind each figure, and the deliverables and timeline agreed in writing. It should also state what is excluded, such as commercial licensing from Collate, cloud account charges you pay directly, and ongoing support. DeployOpen does not publish a price list, so ask for a quote tied to that written scope and check that each assumption can be verified against your environment.
Which OpenMetadata versions and prerequisites should the cost model assume?
Assume the current major release line and its prerequisites, because they affect sizing and maintenance effort. OpenMetadata 2.0.0 was released on August 24, 2026, and bare metal installs need Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Upgrading from 1.x involves breaking changes, including credential format changes and migration of Great Expectations to 1.3, so budget for that work if you run an older install. Confirm the supported versions against the release notes and the bare metal deployment documentation before you finalize the model.
How DeployOpen scopes, delivers and hands over cost of ownership work
DeployOpen treats OpenMetadata cost of ownership as a written, fixed-scope question: which edition fits, where the platform runs, and who maintains it after go-live. Each engagement starts from your deployment target, data stack and stewardship model, so the quote reflects your own environment and its running costs.
How we scope
- The written scope records whether you self-host the Apache 2.0 release or buy Collate's commercial capabilities.
- Infrastructure is sized for your database, search and ingestion footprint, starting from the documented minimums.
- Fixed-scope agreements list deliverables, sizing assumptions and the stewardship roles your team will need to fill.
How we build
- Bare metal builds use Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Connector onboarding, lineage, data quality and profiler settings are configured and tested against your sources.
- Connector credentials, SSO and network paths to sources are configured and checked before any data flows.
How we hand over
- Handover includes runbooks for deployment, backup and restore, ingestion scheduling and upgrade procedures, as agreed in scope.
- Cost records separate one-time build effort from recurring infrastructure and subscription lines, each with a named owner.
- Steward role descriptions show who maintains glossary terms, ownership and data quality failures after go-live.
How we support
- Ongoing support is available as a retainer, covering upgrades and maintenance releases after handover.
- Upgrade plans check 2.0 breaking changes, including embedding credentials and custom ingestion image rebuilds.
- Confirm with Collate which support terms apply to the commercial edition before you compare total cost.
