Metric Definitions as Infrastructure
George Xing, co-founder and CEO of Supergrain, on the future of business intelligence
The key shift is from storing finished answers to storing reusable definitions. A precomputed table can tell a company revenue by day, but if finance wants it by region and product, or a product team wants it by signup cohort, that table no longer works. The metric has been frozen at one grain, so every new cut creates new tables, new SQL, and new opportunities for teams to drift apart on what the number means.
-
This is why metrics layers emerged between the warehouse and the dashboard. Instead of saving revenue as one table, they save the logic for how revenue should be calculated, then generate the right query at runtime for whatever breakdown the user asks for, day, month, city, channel, or product line.
-
The practical problem is organizational, not just technical. At Lyft, different teams were already defining the same business metrics differently across spreadsheets, BI dashboards, and SQL queries. Materializing metrics into fixed tables reduces some ambiguity, but it also pushes teams to keep rebuilding special case tables as questions change.
-
The broader modern data stack moved this way for the same reason. Warehouses became the shared storage layer, while tools like dbt and Supergrain focused on shared business logic that could be used by BI, notebooks, reverse ETL, and planning tools. Value shifted toward the layer that keeps definitions portable across all those surfaces.
The next step is that metrics definitions become infrastructure for software, not just dashboards. As more analytics gets embedded into planning tools, AI copilots, and customer facing apps, the winning layer will be the one that can answer new questions on demand without forcing teams to remodel the warehouse every time the business asks for a different slice.