A multi-tenant SaaS product with a schema per customer has a strange data estate. Say you run 40 tables per customer and have 50 customers. That isn’t 2,000 different tables. It’s 40 tables, 50 times. Sign 10 more customers next quarter and the estate grows by 400 tables while your data team doesn’t grow at all.
Most data observability evaluations are built for the opposite shape: a warehouse of unique tables, each with an owner.
So ask different questions.
Four questions for a multi-tenant evaluation
| Question | Why it matters for multi-tenant | What a good answer looks like |
|---|---|---|
| What’s the pricing unit? | Schema-per-tenant multiplies tables by customers | Users or connections, not tables or events |
| Can a new tenant be onboarded by API? | Provisioning a customer shouldn’t need a person in a UI | Create coverage from the same pipeline that creates the schema |
| Can one suite be reused across identical schemas? | Writing or generating tests 50 times is 50 times the upkeep | Copy or repoint a suite and keep its history |
| Where does tenant data go? | Your customers’ contracts may cover it | Tests run inside your database; only aggregates come out |
The pricing unit decides the bill
Per-table pricing charges you for what your tenants create. DataKitchen’s February 2026 post Stop Paying the Data Quality Tax has the example: a company of 400 people with a six-person data team, 1,000 tables in its main application and 500 in a warehouse. Per-table pricing came to nearly $12,000 a month, over $150,000 a year. DataKitchen cost $9,000.
For scale, DataKitchen’s comparison pages estimate Monte Carlo at $120,000 to $250,000 a year for 10 users and 1,000 tables, on a per-table tier (DataKitchen’s estimate, reviewed June 2026). TestGen Enterprise lists at $100 per user and $100 per database connection per month, unlimited tables. If your tenant schemas live in one database, adding a tenant adds tables, not connections.
DataKitchen sells the per-connection model, so weigh that. But run the arithmetic on next year’s customer count, not this year’s.
Treat tenants as a herd
DataKitchen’s pets and cattle post draws the line: data observability is the cattle approach, broad monitoring across a herd you can’t know one by one. Tenant schemas are the purest herd there is. Same tables, same columns, different customers.
So the test that matters is reuse. In a September 2026 DataKitchen test on 15 million pharma payments, the team built a 369-test suite on one table group, then copied all of it, generated and custom, into a suite on a second table group with the same shape. Running all 369 against 15.5 million rows took 15 minutes 50 seconds on a Mac M1.
The copy worked. The baselines didn’t all travel. 33 of the 353 generated tests broke, because their thresholds came from the first table’s data, while the 16 rule tests held. Expect the same with tenants: rules written from your product’s logic copy cleanly, and generated thresholds need a fresh profile of each tenant.
TestGen’s October 14, 2026 release added the two pieces that make it routine. The REST API can create table groups and test suites, schedule profiling and test runs, and configure monitoring, so tenant provisioning can call it. And a table group can be pointed at a new schema while keeping its tests’ history and predicted thresholds.
Tenant data and new-tenant noise
Many observability tools run as vendor SaaS. Ask where tenant rows go. TestGen pushes read-only SQL into your database and keeps only computed aggregates and test outcomes, as DataKitchen’s Fabric post spells out for a security review.
And plan for the cold start. A tenant signed last week has no history. Learned monitors need about 90 days to know a column’s shape, per the Guide to DataOps Tests, so new tenants start on fixed rules and warn-only monitors.
What this page doesn’t cover: shared tables partitioned by a tenant ID column, per-tenant alert routing, and per-tenant access control. DataKitchen hasn’t published a test of those patterns, so evaluate them in a trial on your own schema.