feat: Add MV granularities and infer config from SummingMergeTree

[pulpdrew]

Closes HDX-3064

Summary

This PR makes two improvements to MV configuration

1. Additional granularities are now available
2. Configuration can now be inferred from SummingMergeTree MVs (in addition to AggregatingMergeTree, which were already supported)
3. Source column inference has been improved to support cases where the target table column name does not follow the aggFn__sourceColumn convention.

Also, tests have been updated and additional tests have been backported from the EE repo.

Demo

Screen.Recording.2026-01-05.at.10.22.42.AM.mov

Testing

To test the Summing Merge Tree inference, create a materialized view like so:

CREATE TABLE default.traces_summed_2              
(                                                
   `Timestamp` DateTime,                        
   `ServiceName` LowCardinality(String),        
   `StatusCode` LowCardinality(String),         
   `count` UInt64,                              
   `sumDuration` UInt64,
   `quantileDuration` AggregateFunction(quantile(0.5), UInt64)                       
)                                                
ENGINE = SummingMergeTree((count, sumDuration))
ORDER BY (ServiceName, StatusCode, Timestamp)    
SETTINGS index_granularity = 8192;

CREATE MATERIALIZED VIEW default.traces_summed_mv_2 TO default.traces_summed_2
(
      `Timestamp` DateTime,
      `ServiceName` LowCardinality(String),
      `StatusCode` LowCardinality(String),
      `count` UInt64,
      `sumDuration` UInt64,
      `quantileDuration` AggregateFunction(quantile(0.5), UInt64)
)
AS SELECT
      toStartOfInterval(Timestamp, toIntervalMinute(30)) AS Timestamp,
      ServiceName,
      StatusCode,
      count() AS count,
      sum(Duration) AS sumDuration,
      quantileState(0.5)(Duration) AS quantileDuration
FROM default.otel_traces
GROUP BY
      Timestamp,
      ServiceName,
      StatusCode;

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
hyperdx-v2-oss-app	Ready	Preview, Comment	Jan 6, 2026 7:45pm

[changeset-bot]

🦋 Changeset detected

Latest commit: 60dff26

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@hyperdx/api	Patch
@hyperdx/app	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[claude]

Code Review

✅ No critical issues found.

The PR successfully adds MV granularities and SummingMergeTree support with comprehensive test coverage. The implementation follows HyperDX patterns correctly.

Minor observations:

• ✓ Type safety maintained throughout with proper type guards
• ✓ 698 lines of tests added with good edge case coverage
• ✓ Graceful fallbacks when inference fails
• ✓ Notification IDs added (good UX improvement)
• ✓ Exported constants follow existing patterns

Recommendation: Approve and merge ✅

[github-actions]

E2E Test Results

✅ All tests passed • 56 passed • 4 skipped • 731s

Status	Count
✅ Passed	56
❌ Failed	0
⚠️ Flaky	0
⏭️ Skipped	4

Tests ran across 4 shards in parallel.

View full report →

[wrn14897]

should we check other agg functions here?

[pulpdrew]

For AggregatingMergeTree, we do. But for SummingMergeTree, the behavior is that the summedColumnNames (which are the arguments passed to the engine eg. SummingMergeTree([...columns])) are all summed. That's only valid for sums and counts - so we handle count as a special case and assume others are sums.

SummingMergeTree does technically support other aggregations if the Column has AggregateFunction type - in which case the .map above will cover that case. I'll update the test case to show that.

[wrn14897]

I wonder if we could use mv DDL to figure out the mapping cuz users don't need to follow these conventions to map source table columns, right?

[pulpdrew]

We can in most cases! I've updated getSourceTableColumn to extract the column definitions from the materialized view DDL and try to match up source and target column names, if the convention-based matching fails. The user always has the option to explicitly configure the source column name, in case the inference fails though (such as due to multiple MVs writing to the table, or unexpectedly complex expressions).

[wrn14897]

lgtm