Data catalog RFP questions to ask before you choose a partner
Before you choose a partner to deploy a self-hosted catalog, put the same written questions to every candidate and score their answers against shared criteria. Ask each partner whether they would build an internal catalog on OpenMetadata or DataHub, or a published data portal on CKAN, and require a clear reason for that choice tied to your use. The answers to this question, and to the questions in the rest of this section, should be the basis of your decision.
Send the questions in writing and ask for named examples of past work, along with the written scope each partner would propose. Named examples let you check which connectors they have configured, how they handled lineage capture and what the upgrade path looked like. Written scope lets you compare what each partner includes, such as connector setup, glossary bootstrapping, stewardship training and handover documentation. Score each answer against the same criteria, and record any answer that is vague, unsupported by an example or dependent on a capability you have not confirmed.
Both OpenMetadata and DataHub are released under the Apache License 2.0, so license fees will not separate the candidates. The comparison will turn on the partner's experience with your sources, their approach to ownership and personal data tagging, and their operating model for upgrades. Ask each partner to confirm which of these they will deliver, which they expect you to own, and what you should verify in your own environment before signing.
Which connectors and lineage questions separate credible partners
How many data catalog connectors should a partner configure out of the box?
No partner should answer with a single number before seeing your source list. OpenMetadata lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms, and DataHub lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Those counts describe what the projects ship, not what your estate needs. Ask the partner to map each system in your inventory to a named connector, a connector version, the ingestion method and the owner of each credential. A credible answer lists the systems you named, flags any without a connector, and states which of them are scoped for the engagement and which are excluded in the written scope.
What happens when a source system has no supported connector?
The partner should describe a fallback path before the work starts. Common options are a custom ingestion script built on the catalog's REST API or Python SDK, a metadata file export from the source loaded on a schedule, or manual entries for a small set of critical assets. Each option carries a different maintenance burden. Custom connectors need owners, tests and a plan for upgrades, because they will not receive updates from the catalog project. Ask who writes and maintains the custom code after handover, where it runs, how failures are alerted, and whether the cost is part of the fixed scope or a later change request.
How is lineage captured from pipelines in OpenMetadata or DataHub?
Lineage comes from two sources, and a credible partner separates them. The first is metadata ingestion, where the catalog reads query logs, view definitions, transformation tools and pipeline metadata. The second is event-based capture, where pipelines emit lineage as they run. OpenMetadata supports OpenLineage event integration for table, column, dashboard, pipeline and metric lineage. Ask which pipelines emit OpenLineage events, which rely on ingestion alone, and what happens to lineage from pipelines that use neither, such as hand-written SQL in scripts. Ask how the partner tests a lineage edge end to end, for example by changing a source column in a test environment and confirming the downstream report appears in the graph.
How deep should column-level lineage go, and who decides?
Depth is a scope decision, not a default setting. Table lineage is the minimum most estates need, while column-level lineage is needed where a report figure must be traced to its source fields, which is common in regulatory reporting. DataHub lists column-level lineage among its features, and OpenMetadata covers column lineage as well. Ask the partner to agree in writing which reports, critical data elements and pipelines require column-level lineage, which accept table-level only, and how parsing gaps are reported. Parsers do not read every dynamic SQL statement, so the partner should state how unresolved edges are flagged and who reviews them.
What does it cost to run the connectors and lineage ingestion over time?
The open-source license is free, so the costs are work and infrastructure. One-time costs include connector configuration, credential setup, lineage testing and the first full ingestion. Recurring costs include ingestion compute, the database and search services the catalog depends on, connector upgrades, and fixes when a source schema changes. OpenMetadata's bare metal documentation lists minimum server sizing of 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Ask for a quote that separates one-time configuration from recurring operations and states how many connectors and pipelines are included.
How does the partner keep connectors working after catalog upgrades?
Connector behavior changes between catalog releases, so ask how each upgrade is tested before production. OpenMetadata 2.0 introduced breaking changes that touch ingestion, including a new Databricks auth format and rebuilt custom ingestion images for Python 3.12, so connector configuration and custom code need checking at every major step. Ask the partner to show a connector regression test set, a staging environment that mirrors production sources, and a rollback plan for ingestion images. Ask which connector versions they have tested against each catalog release and who approves a connector change.
How does the partner confirm that lineage matches what engineers see?
A credible partner shows a validation method rather than a graph screenshot. Ask them to pick a sample of critical reports and trace each one back to its source tables, then compare the catalog graph with the transformation code and the pipeline run history. Ask how they handle lineage that spans systems the catalog does not read, and how stale edges are removed after a pipeline is retired. The answer should name who signs off the sample, how many discrepancies are acceptable before rework, and how the results are recorded for later audits.
How personal data gets tagged for records of processing
The partner's method for finding personal data decides how much the catalog can contribute to GDPR Article 30 records of processing, so ask for it in writing before scoping. Column-name rules are fast and transparent: a column called email_address or date_of_birth is tagged because its name says so. They miss personal data hidden in free text, codes and renamed fields. Entity recognition on sampled values catches those cases but produces false positives, such as product codes that look like national identifiers. OpenMetadata supports auto-classification, and the partner should explain which rule set and recognizers it configures, which sample sizes it uses and how it handles sensitive sources such as clinical or payroll tables.
Ask how confidence thresholds are set and who signs off on them. A high threshold reduces noise but leaves gaps, and a low one floods stewards with candidates. The partner should document the threshold per classifier, run a baseline on a representative set of tables and record the precision observed in that test. Then ask how PII tags map to confidentiality labels in your classification scheme, and whether that mapping is written down as a controlled decision, not an analyst habit. Confirm who reviews results: typically the dataset owner confirms, a privacy lead approves categories for records of processing, and reviewed tags are retained with a date and reviewer name.
The catalog supports records of processing but does not replace the controller's legal assessment of purposes, lawful bases, recipients and retention. Treat auto-tagged output as an inventory input that the privacy team validates. DeployOpen configures the classification, review workflow and evidence exports and documents how they operate, but it does not issue audit reports, attestations or certifications. Independent auditors and supervisory authorities judge whether your records are adequate. Ask the partner to show how each reviewed tag traces back to a dataset, an owner and a processing activity.
Answers that should worry you in a catalog RFP
A catalog partner's answers reveal whether they have run a metadata program before or only installed one. The red flags below share a pattern: the partner treats the catalog as a software install, when the hard work is connectors, lineage capture, people who own data, and sustained adoption. Use them to probe every bid.
All sources connect out of the box
Connector coverage is a starting point, not a finished job. Each source needs credentials, network paths, ingestion schedules, filters for schemas and databases, and a check that the metadata arrives correctly. Ask which connectors the partner will configure in your environment, which they will build custom, and how they verify each one against a named source system. Be cautious of any answer that counts connectors without describing configuration work.
Lineage without a capture method
Lineage claims mean little until the partner names how it is captured. Table-level lineage from SQL parsing differs from column-level lineage, and pipeline lineage depends on orchestrators emitting events. Ask whether lineage comes from OpenLineage events, query log parsing, dbt manifests or manual entry, and which pipelines will be covered at launch. A partner who cannot answer this has not designed the lineage you need for risk or regulatory reporting.
Ownership treated as a tool setting
A catalog can display an owner field, but naming accountable people is a governance task. A serious partner plans how owners are nominated, who approves them, how stewards are trained, and what happens when an employee leaves. Ask who runs the ownership workshops, how the first owners are bootstrapped for critical datasets, and how ownership gaps are reported to leadership. If the answer is a configuration screen, the catalog will decay within months.
Personal data tagged with no review step
Automated classification will mislabel columns, both missed personal data and false positives. Ask how automatic tags are reviewed before they feed records of processing or confidentiality labels, who signs off, how confidence thresholds are tuned, and how tag changes are logged. An illustrative case: a column named for customer codes may be tagged as personal data without review, which then inflates a records of processing entry. Any partner offering tags without a review workflow is leaving compliance evidence to chance.
No adoption plan
A catalog that nobody searches delivers no value, yet many bids price only installation. Ask what the partner will do to drive use: onboarding for data producers and analysts, glossary workshops with business owners, integration into existing data tools, and usage metrics reviewed with the sponsor. Also ask who maintains content after go-live and how that effort is budgeted. Silence on adoption usually means the project ends at handover.
No upgrade path for breaking changes
Open-source catalogs change between major versions in ways that break existing setups. OpenMetadata 2.0 introduced breaking changes, including moved embedding credentials, a new Databricks auth format, and a required Python 3.12 rebuild of custom ingestion images. Ask the partner to walk through how they test a new release in a staging copy, which migration steps they follow, how rollback works, and how they communicate downtime. A partner who cannot describe this has not operated the platform through an upgrade.
How OpenMetadata and DataHub upgrades are handled
OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases 2.0.1 to 2.0.5 have followed about every one to two weeks. The 2.0 release notes list breaking changes that a partner must plan for before any upgrade from a 1.x deployment. Ingestion and credential configuration are the areas most likely to need rework, so the upgrade plan should be written against those items rather than the general release summary.
- Embedding credentials: Embedding credentials move into an
llmConfigurationblock, so any existing configuration that stores them in the old location must be rewritten and tested. - Databricks authentication: A new Databricks auth format applies, and connector definitions for Databricks sources need to be checked against it.
- Custom ingestion images: Custom images must be rebuilt for Python 3.12 and the Apache Airflow 3.3.0 base that 2.0 ships with.
- Great Expectations migration: Great Expectations must be migrated to 1.3 before the upgrade, so any data quality tests that depend on it need prior validation.
- Default changes: Dynamic Sampling is now the profiler default and MCP is enabled by default, which can change ingestion load and API exposure after upgrade.
Ask the partner to produce a written list of which of these items apply to your connectors and configuration before scoping the upgrade.",
DataHub is deployed on Kubernetes with Helm charts from the acryldata/datahub-helm repository, alongside a separate prerequisites chart for Kafka, the database, Elasticsearch and the graph index. The Helm chart runs a system-update job on upgrades that applies schema changes and reindexes search indices when needed. That job is the step most likely to take noticeable time on a large metadata estate, so the partner should measure it in staging rather than assume it.
- System-update job: Confirm how the job is triggered, what it changes in the database and the search index, and whether it can be re-run safely if it fails midway.
- Reindexing impact: Ask how search availability is affected while reindexing runs, and whether users see stale or partial results during that window.
- Component versions: Check that the GMS, MAE Consumer, MCE Consumer, Frontend, Kafka and search versions remain compatible across the upgrade path.
- Prerequisite chart changes: Confirm whether the prerequisites chart changes at the same time as the main chart and how those changes are sequenced.
- Release candidates: Ask whether the partner will upgrade only to stable releases, given that release candidates were published in October 2026.
Ask the partner to show a dry run of the Helm upgrade and the system-update job against a copy of your metadata before any production change.",
Both platforms need the same operational discipline: a rehearsal on a copy of production, a documented way back, and a steady process for tracking releases. Without these, an upgrade that succeeds in a test environment can still fail in production because of data volume, connector differences or changed defaults. The partner should describe each control in writing and say who approves the move from staging to production.
- Staging rehearsal: Ask for a rehearsal on a restored copy of the production database and search index, with ingestion runs and connector tests executed afterward.
- Rollback plan: Ask how the database, search index and container images are backed up before the upgrade, and how each would be restored, with the time needed for restore confirmed in the plan.
- Release tracking: Ask how new OpenMetadata and DataHub releases are monitored, who reviews release notes, and how security fixes are scheduled against feature upgrades.
- Change approval: Confirm which change record, test evidence and sign-off your organization needs before production upgrades proceed.
- Upgrade cadence: Agree whether upgrades follow a fixed cycle or are driven by security advisories and the vendor's release schedule, and whether that work is covered by a retainer or quoted separately.
Ask the partner to provide a sample rollback runbook and a record of the last upgrade it performed on either platform.
How to score partner responses
This table compares full, partial and missing partner answers across the criteria that matter most for a catalog rollout. Use it to read each response against the evidence you would expect to see, not to add up points. A partner that answers every row with specifics and named artifacts is showing the working knowledge a catalog project needs.
| Criterion | Full answer | Partial answer | Missing answer |
|---|---|---|---|
| Connectors | Names each source system, the connector version, the auth method, and who configures the ingestion schedule and secrets | Lists connectors generically or covers only the warehouse and BI tools, with credentials handling left open | Says connectors are available without naming sources or describing setup |
| Lineage from pipelines | Explains how table, column and pipeline lineage is captured (for example through OpenLineage events or ingestion metadata) and which gaps need manual lineage | Covers table-level lineage only, or says column lineage will follow after go-live | Offers no method for capturing lineage from orchestrators or transformation code |
| Ownership and glossary bootstrap | Describes how owners are assigned from source systems and HR or identity data, how the glossary is seeded, and who approves changes | Proposes a glossary workshop without a seed source or a sign-off step for ownership | Leaves ownership and definitions to the client with no proposed process |
| Personal data tagging | Shows how classifications are applied, how rules and sample-based detection are tuned, who reviews tags, and how tags feed a records of processing view | Mentions classification as a feature but does not describe review, tuning or links to processing records | No method for finding or tagging personal data |
| Adoption | Sets out a rollout by domain with named stewards, usage measures the client can inspect, and training tied to real workflows | Offers training and a launch event but no owner, measure or follow-up after launch | Treats adoption as the client's responsibility |
| Upgrades | Covers the version policy, a staging upgrade with tests, handling of breaking changes and migration steps, and how search reindexing and schema updates are run | Says upgrades are supported but does not describe staging, rollback or breaking change review | No upgrade method, or upgrades are described only as future retainer work |
| Security and SSO | Describes OIDC or SAML setup in the client's identity provider, role mapping, secrets storage, network placement and hardening | Confirms SSO support without naming the identity provider flow or role mapping | SSO and access control are not addressed |
| Evidence for audits | Lists the configuration, access, ingestion and change records the client can export, and where they are kept | Refers to logs or documentation without saying what is retained or for how long | No evidence plan, or evidence is assumed to come from the vendor |
What drives cost and effort, and what the RFP should ask for in a quote
The licence line is zero for the catalog itself. OpenMetadata and DataHub Core are both released under the Apache License 2.0, so the spend is in four places: infrastructure for the metadata database and search service, connector and lineage setup by engineers, metadata curation and stewardship by the business and data owners, and ongoing operations. The partner is paid for the first two and often the last, while stewardship time stays with your own staff. Ask the partner to split the quote along these lines so you can see which costs you carry internally. Ask whether the connector list is priced per source system or covered in one scope, and whether lineage work for pipelines such as Airflow or Dagster is a separate line item.
Some costs are one-time and others recur. Connector configuration, initial ingestion, SSO and role mapping, and the first glossary and ownership bootstrap are one-time work and should be listed as deliverables with acceptance criteria. Infrastructure, search reindexing, backups, monitoring, and version upgrades recur for as long as the catalog runs. Upgrades deserve specific attention: OpenMetadata 2.0 introduced breaking changes that required rebuilding custom ingestion images and migrating Great Expectations before upgrading, and DataHub's Helm chart runs a system-update job on upgrades. Ask the partner to name the upgrade procedure, the test environment used, and who signs off on the change. The quote follows from written scope, and ongoing support and upgrades are typically covered by a separate retainer, so ask for that price as a distinct line.
How DeployOpen scopes, delivers and supports catalog engagements
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted catalog platforms inside the client's own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written scope that answers the RFP questions on connectors, lineage, ownership, personal data tagging, adoption and upgrades before any build work begins.
How we scope
- Written scope lists the source systems and connectors to configure, agreed before work starts.
- Lineage depth is set in writing: table, column, dashboard and pipeline levels, with named pipelines and orchestrators in scope.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ask for the named exclusions too.
How we build
- Deploy the chosen catalog, either OpenMetadata or DataHub, with its database and search services in your environment.
- Configure connectors, OpenLineage or ingestion pipelines, glossary, domains and classification rules, then test them against sample data.
- Document the PII tagging rules, review queue and ownership assignments so your stewards can verify each result.
How we hand over
- Hand over runbooks for deployment, connector maintenance, backups and the upgrade procedure, including breaking-change checks.
- Deliver configuration as code and a record of decisions, so the team can reproduce the setup and audit it later.
- Provide evidence packs for assessors, such as classification rules, ownership records and lineage exports, scoped to your controls.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Upgrade planning covers release notes, migration steps and test runs in a non-production copy before any production change.
- Use the retainer to add connectors, tune classification confidence and extend lineage as new systems come online.
