How Mitratech cut new customer data onboarding from six weeks to three days with dbt

Brian Kasen, director of data engineering and analytics at Mitratech, and Abhra Gupta, a data engineer on his team, walked through how Mitratech's data platform group turned a growing pile of one-off data requests into a productized offering called DataShare. The session covered how the compliance software company used dbt, not just for transformations but as an orchestration layer, to shift from being a cost center to a profit center.

Mitratech is a compliance software company built largely through acquisition, with three divisions (legal, HR, and governance and risk compliance) spanning 20 to 30 products. Kasen's team joined through the Trakstar acquisition in 2023, and Mitratech has made eight or nine more acquisitions since, each bringing its own tech stack and data sources.

Departments kept asking Kasen's team to pull data out of one more SaaS product for someone else's dashboard, usually through custom Python scripts hitting a vendor API. Every product had its own schema, its own tenancy model (single-tenant, multi-tenant, or customer-hosted), and often sensitive legal or HR data that needed real governance.

The first version of DataShare, built with partner phData for Mitratech's Align governance and risk product, used Snowflake reader accounts so customers without their own Snowflake instance could still query the data (Mitratech calls this "bring your own BI"), or a direct Snowflake-to-Snowflake secure share for customers who already had one. It worked, and it turned the data team into a source of new upsell revenue instead of just backend plumbing, but it was built specifically for Align, so every new product meant going back to the whiteboard.

The rebuild made dbt the orchestrator, not just the transformation layer. The DataShare package isn't a normal dbt project: it has no models, seeds, or tests, just macros organized into provisioning, deprovisioning, metadata, and logging, which install and call Snowflake stored procedures through dbt run-operation.

A 5-phase pipeline builds the schemas, control and log tables, secure views, and Snowflake share objects, applying tenant-level and customer-level filters, PII exclusions, and encryption straight from configuration. The key move was separating configuration from code.

Four control and log tables mean Mitratech's CloudOps team, who aren't developers, can onboard a new customer as a data-entry task instead of an engineering request, running a single dbt command to provision or deprovision a customer.

The results were dramatic. CloudOps time per request dropped 97 percent, from an estimated 26 to 40 hours down to a couple of platform commands, and delivery time fell from 3 to 7 business days to about one day.

Onboarding a brand-new product to DataShare dropped from 3 to 6 weeks to 1 to 3 days, roughly 90 percent faster, with a full audit trail captured automatically in Snowflake.

Kasen and Gupta's main takeaway: design for generalization from the start, because the second customer request is what forces the refactor anyway. They also pitched dbt macros as infrastructure in their own right, since they bring version control and idempotency to Snowflake objects that normally live outside any repository.

The team is also experimenting with a wider set of AI tooling to keep building quickly, including Cognition's Devin and Claude Skills today, with dbt Wizard and Snowflake CoCo next on their list.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →