More than 80 connectors feed one searchable metadata graph
DataHub's README lists more than 80 connectors for warehouses, lakes, BI systems, orchestration tools, and machine-learning platforms. They send schemas, ownership, usage, profiles, and lineage into a shared metadata graph. People can search that graph, browse relationships, attach glossary terms, and apply policies. APIs and event streams let internal tools use the same context. This breadth pays off when data is spread across enough systems that nobody can answer where a table came from or who owns it.
Collection does not create governance by itself. A Snowflake recipe still needs a permitted account, warehouse details, and decisions about which databases to include. Owners must review descriptions, terms, domains, access rules, and stale assets after ingestion. The more than 80 connectors reduce custom integration work; they also create many moving parts with different authentication, rate limits, and lineage depth. A useful pilot should include the hardest source, not only the cleanest warehouse.
The 8 GB quick start runs five major services
The documented local setup asks Docker Desktop for at least 8 GB of memory and starts GMS, a React interface, Elasticsearch, MySQL, and Kafka. Default credentials make the sample environment easy to open at port 9002, but they must not survive outside a disposable machine. Production guidance points self-hosters toward Kubernetes and Helm. Storage persistence, TLS, authentication, search sizing, Kafka retention, backups, and secret rotation all become operator work.
DataHub Actions adds event-driven automation on top. Its current source is Kafka, and it can filter entity changes, transform them, then run custom code or notifications. One process may host several pipelines. This is useful for reacting to a tag, owner, or metadata log event, yet custom actions can call external APIs and change other systems. Run them with narrow credentials, make handlers safe to retry, and retain enough event detail to explain why an action fired.
What happened when we ran it
Our sandbox targeted datahub-actions inside commit 837b2ac, not the full DataHub service stack. Installation took 72 seconds, pulled 178 packages, and occupied 428 MB. The Python build succeeded in 11 seconds. The full repository checkout was 246.9 MB with 19,270 files and roughly 2,474,356 source lines, which explains why changing DataHub from source is a different job from installing one published connector package.
Pytest ended after 216 seconds with 191 passed and 13 failed out of 204. The supplied log tail lists PgQueue acknowledgement, configuration, and event tests. Those cases stopped on Pydantic ValidationError messages reporting 4 configuration errors. The log does not establish why those values failed validation, so the defensible result is simply that this target did not pass in our fresh 3-CPU, 8 GB Debian environment.
Pip-audit found 2 known vulnerabilities in the installed Python dependency set. The repository scan found 53 CI workflow files and a tests directory, while the measured Actions target had no Dockerfile. These signals show substantial automation, but they do not cancel a red local suite. Before writing production actions, reproduce the PgQueue cases with the same configuration and audit the 2 reported packages against the versions and call paths you will deploy.
Version 1.7.0.1 requires a stop at 1.6.0 for older installs
The September 3 v1.7.0.1 release is a patch on the v1.7 line, with separate CLI 1.7.0.9 and Helm chart 1.1.0 requirements. Its upgrade notes say deployments older than 1.7 must first move to v1.6.0 with chart 1.0.3 and let the system update finish. Skipping that step is explicitly forbidden. This is a change window that needs a database and index backup, a rollback plan, and observed completion of the intermediate job.
The same release removes the old built-in system client secret and tells affected operators to set DATAHUB_SYSTEM_CLIENT_SECRET across GMS, consumers, the frontend, and Actions before upgrading. It also tightens permissions for timeseries reads and membership writes. Those are worthwhile security changes, but a careless image bump can break clients or internal jobs. Inventory every service using the system identity and test permission-sensitive automation before changing the production chart.
Large Tableau catalogs have a current truncation warning
Open issue 19689 documents 4 problems on large Tableau Cloud instances: unstable cursor pagination, fatal handling of rate limits, crashes on truncated nested responses, and field-lineage pages exceeding Tableau's limit. The report says the last case can silently produce incomplete upstream fields. Teams using Tableau at that scale should run count comparisons and lineage samples against the source before accepting an ingestion job as complete. A green pipeline status would not expose silent truncation.
Connector-specific failures are the practical price of a broad catalog. OpenMetadata is the closest like-for-like alternative and deserves the same source-by-source trial. Marquez has a smaller scope around OpenLineage jobs and datasets, which can be preferable when governance workflows are unnecessary. Compare coverage using your own schemas, deleted assets, permissions, and rate limits; screenshots of a sample catalog reveal little about whether production metadata stays accurate.
A 1,306-item queue still moved on September 11
GitHub showed 12,678 stars and 1,306 open issues and pull requests on September 11, 2026: 522 issues and 784 pull requests. The repository was pushed that day, and both issue and pull request activity continued during the same week. That is an unusually large review queue, not a count of 1,306 bugs. It shows an active project with a great deal of parallel change, so version pinning and release-note review matter more than the age of the v1.7.0.1 tag.
DataHub is worth the operational cost when catalog search, lineage, ownership, policy, and metadata automation are one connected requirement. Our 191 passing Actions tests show substantial executable coverage, while the 13 failures block an unqualified recommendation for that subproject. Start with two representative sources, measure missing and duplicated entities, assign real owners, and rehearse one upgrade. If that trial does not change how people find or govern data, the five-service stack is solving a problem the organization does not yet have.