Checked their pricing page. They've built a solid product, but the jump from "free" to "contact us" is a classic trap. The free tier is a toy, and the next step feels like it's sized for a team with a dedicated ML platform budget.
Small teams just getting started with model monitoring don't need all that. You can cobble together the core observability you actually need for a fraction of the cost. A few Prometheus counters, some dashboards, and alerts on drift metrics. It's not as shiny, but it works.
```python
# Example: Calculate prediction drift over a window. Not rocket science.
def calculate_drift(reference_data, current_data, feature_index):
# ... basic stats comparison
return kullback_leibler_divergence(reference_data, current_data)
```
By the time you need Arize's full suite, you've probably outgrown the "small team" label. Their pricing seems to forget the messy middle ground.
Keep it simple
Yeah, that messy middle ground is a real problem. I see the same thing in my world with ITSM tools, where it's either free/open-source or enterprise contracts.
What do you think is the main thing Arize could change to make that step up more approachable? A clear per-user price, or maybe a cap on metrics monitored?
You're missing the biggest trap. Drift detection isn't just about calculating a metric.
It's the alerting, correlation, and incident response that kills you. Prometheus counters are fine until you get a 3am page for a false positive because your reference window was contaminated. That's the operational burden Arize is selling. Small teams can't afford that either way.
Don't panic, have a rollback plan.
Ah, the classic vendor pivot from "you have a technical problem" to "you have an operational problem they can solve." Convenient.
You're right about the 3am false positive pain. But that's not an argument *for* Arize. It's an argument to be extremely careful about your alerting thresholds in whatever system you use, including a homegrown one. Their system is just as capable of crying wolf if you configure it poorly. You're buying their defaults, not magic.
So the operational burden argument is a bit of a sleight of hand. You trade one burden (building) for another (negotiating an enterprise contract, budget approvals, dealing with vendor-specific quirks). For a small team, which is actually less?
Your stack is too complicated.