Every vendor sells you on setup time, and DataKitchen’s own Guide to DataOps Tests says table monitoring on a bronze database takes about an hour to stand up. Setup is a one-time cost. The question is what the tool costs you every Tuesday after that.
DataKitchen hasn’t published a weekly-hours benchmark. So this page gives you the tasks, what each one scales with, and a template to fill in.
The weekly tasks, and what drives each one
| Task | What it scales with | Sourced reference point |
|---|---|---|
| Alert triage | Tables × noise rate | None published. Count it in your trial |
| Threshold tuning | New tables, new learned monitors | Run statistical checks warn-only first, per the efficiency post |
| Incident review | Real incidents | 15 minutes per written postmortem, same post |
| Rule review | Rule count | Once a quarter with the people who use the data, per the Guide |
| Upgrades | Installs | None published. Self-hosted means you schedule them |
| Credential rotation | Connections | None published. Follows your security policy |
| Warehouse compute | Test runs × data size | 69 tests on 2,964,624 rows ran in 6 seconds in the NYC taxi exercise |
Look at the middle column. That column is DataKitchen’s reasoning, not a measurement: only the first two rows grow with your table count, and upgrades and credentials grow with installs and connections. So our advice to a team going from 100 to 1,000 tables is not to plan on ten times the hours. Plan on more alerts, and on a noise rate that decides whether that’s fine or a disaster.
Compute is the line we’d bet you overestimate. The migration post ran 345 Table Comparison tests in five seconds. The FITT post puts the ordering plainly: data engineering time costs far more than compute, which costs more than storage. Check your warehouse bill in a trial anyway, since per-second and per-credit pricing differ.
The cost that isn’t on the weekly list
Writing tests by hand. The Medallion testing post prices a hand-written test at 30 minutes, so 2,500 tests take 1,250 hours. Spread over a year, that dwarfs every row above. If your tool generates the baseline from a profile, that cost mostly disappears and the business rules are what’s left. If it doesn’t, it’s the number to put in front of whoever approves the budget.
Size it for 10, 100, and 1,000 tables
The test counts below apply DataKitchen’s coverage standard from the Guide: two to three tests per table and at least two per column. They assume 10 columns per table, the average the Guide uses for its bronze layer. The hours column is arithmetic on the Guide’s 30-minute figure, not a measurement. Your column count will differ.
| Tables | Table tests | Column tests | Hand-written at 30 minutes each |
|---|---|---|---|
| 10 | 20 to 30 | 200 | About 110 to 115 hours |
| 100 | 200 to 300 | 2,000 | About 1,100 to 1,150 hours |
| 1,000 | 2,000 to 3,000 | 20,000 | About 11,000 to 11,500 hours |
The worked example below is illustrative, not DataKitchen data. Replace every input with your own.
Say your trial shows 100 tables producing 20 alerts a week, and that 12 of them needed no action. Say each one takes 10 minutes to check, and a real incident takes 2 hours to fix plus its 15-minute postmortem. Then triage is 20 × 10 minutes, about 3.3 hours. Eight real incidents is 18 hours, and that part isn’t the tool’s fault. Add upgrades and credential rotation as whatever your last one took, divided by the weeks between them.
Now hold everything constant and go to 1,000 tables. At the same noise rate, triage alone is about 33 hours a week.
That’s most of a working week, and 20 of those hours go to alerts that needed no action.
So the number to drive down is the share of alerts that need no action, and the false-positive answer covers how.
For the license side of the bill, see what data quality software costs a small team. For keeping all of this small from the start, see low-overhead monitoring for startups.