The dbt Hub lists 400+ packages. There is no formal governance body, no review process for new additions, and no certification of package quality or security. Understanding who’s behind a package tells you more about whether to trust it in production than any number of stars or downloads.
The Three Tiers of Maintainers
dbt Labs
dbt Labs maintains the core utility packages that almost every project uses:
- dbt-utils — 50+ macros for SQL generation, cross-database compatibility, and generic tests. The closest thing to a standard library the ecosystem has.
- dbt-codegen — Generates boilerplate YAML from database metadata
- dbt-audit-helper — Macros for comparing relations during migrations and refactors
- dbt-project-evaluator — Lints your project against best practices
dbt Labs also operates the Hub itself and defines the package specification. These packages get first-party attention when dbt Core releases introduce breaking changes. If a new dbt version deprecates a macro pattern, dbt-utils gets updated before community packages do.
For long-term reliability, these are the safest bets. The downside is that “safe” also means “conservative” — dbt-utils doesn’t add macros for niche use cases, and major versions move slowly.
Fivetran
Fivetran is the largest non-dbt-Labs contributor, maintaining 100+ packages under Apache 2.0 licenses with five full-time engineers dedicated to dbt package work. If your project uses Fivetran connectors, these packages represent a significant amount of transformation work already done for you — base layer cleaning, mart construction, and cross-platform bundles.
The October 2025 merger between dbt Labs and Fivetran means this investment is likely to deepen. Tighter integration between connectors and transformation packages is the obvious commercial direction, and there’s already evidence of it in how the Fivetran packages are structured and maintained.
One community concern worth noting: as the entity controlling both the most popular ingestion tool and the most popular transformation tool closes ranks, questions about long-term openness of dbt Core are legitimate. The packages are Apache 2.0, but the platform they run on is increasingly commercial.
Community Contributors
Everyone else falls into the community category: Calogica/Metaplane (dbt-expectations, dbt-date), Elementary Data (observability), and individual contributors behind tools like dbt-osmosis, dbt-coverage, dbt-artifacts, and dbt-profiler.
Quality in this tier is highly variable. The best community packages (dbt-expectations, Elementary) are genuinely excellent and production-proven across thousands of installations. Others are maintained by individuals who might move on, change jobs, or simply stop responding to issues.
There is no standardized review process for Hub listing. A package gets added through a PR to the Hub repository, and after a basic sanity check, it’s listed. The Hub is a registry, not a curated marketplace.
How to Evaluate a Package Before Production
When evaluating a community package, apply the same judgment you’d use for any open-source dependency:
GitHub activity
- When was the last commit? Last merged PR?
- Are issues getting responses, or do they sit unanswered for months?
- Is there a CHANGELOG that documents what changed between versions?
Maintenance signals
- Does the package have CI? Does it pass?
- Is there a Fusion compatibility badge on the Hub? (Signals the maintainer is keeping up with dbt’s evolution)
- Are there open issues about compatibility with recent dbt versions?
Adoption
- How many GitHub stars? (Crude but not meaningless)
- Are there references to it in the dbt Slack community?
- Are companies with public case studies using it?
License and ownership
- Is the license compatible with your use case?
- Is it maintained by a company or an individual? Companies are more likely to sustain maintenance; individuals may abandon it.
The six-month test The relevant question isn’t “is this actively maintained today?” but “will someone still be merging PRs six months from now?” If the package is critical to your pipeline, you need to be confident that security updates, dbt version compatibility fixes, and bug fixes will continue to land.
The Hub Is a Registry, Not a Seal of Approval
The dbt Hub explicitly does not certify the integrity or security of listed packages. The listing process is lightweight by design — that’s what enables the ecosystem to grow. But it means you cannot assume a Hub listing implies quality, security review, or ongoing maintenance.
This is fine for most packages, most of the time. dbt packages are SQL and Jinja — the blast radius of a buggy or malicious package is limited compared to, say, a Node.js package with access to your filesystem. But for packages processing sensitive data or running in production pipelines with financial consequences, the evaluation still matters.
Think of the Hub like npm or PyPI: a useful registry that gets you to code quickly, not a guarantee that the code is production-ready. The difference is that dbt’s ecosystem is smaller, so the signal-to-noise ratio is better, and the community in the dbt Slack is a reliable source of opinion on which packages are battle-tested.
The Practical Takeaway
For production use:
- dbt Labs packages: use freely, update regularly, high confidence in maintenance
- Fivetran packages: use when you’re using the corresponding connector; production-proven at scale
- Community packages with broad adoption (dbt-expectations, Elementary): treat like any mature open-source dependency — pin your version, test on upgrades, read the CHANGELOG
- Community packages from unknown maintainers: evaluate carefully before adding to production pipelines; consider forking if the package is small and you can’t trust its maintenance trajectory