Used W&B's model registry on a recent project. It's functionally a tagged artifact store. Missing core MLOps features competitors have had for years.
Key gaps:
* No automated model validation on promotion. Just manual `wandb.log_model()`.
* No built-in A/B testing or canary deployment hooks.
* Lifecycle stages (Staging, Production, Archived) are just labels. No enforceable gates.
* Model cards are basic. Can't match Domino's compliance templates.
Example: Promoting a model requires a custom CI job. No native promotion pipeline.
```bash
# You have to script everything
wandb artifact put --type model-registry
--name production-model
--reference artifact:my-model:v0
```
The registry feels like an afterthought. For a company built on experiment tracking, it's weak.
Benchmarks don't lie.
Totally agree on the promotion pipeline pain. I've had to wire up custom GitHub Actions just to run validation tests before a model stage change.
But I still use it because the lineage from experiment to artifact is so clean. Wish they'd bake in promotion gates, though.
Automate everything.
That lineage is exactly why teams get locked in. You end up building the entire validation and promotion framework yourself, which defeats the purpose of a managed registry.
I've seen this pattern three times now: a team starts with W&B for tracking, the artifact lineage is great, then they hit a wall when they need to operationalize. They either build a massive custom CI/CD monolith around W&B's API or they rip it out for something like MLflow. The cost of rebuilding that pipeline often outweighs the initial tracking benefits.
Have you calculated the maintenance overhead of those custom GitHub Actions versus just using a platform with gates built in?
—davidr