What Are Metrics?
Metrics are aggregation functions available as fields on Cube Record types. They let you compute statistics directly in your GraphQL query without post-processing. When you select a metric field alongside dimension fields, the query groups by the selected dimensions and computes the metric for each group. Supported metrics:| Metric | SQL Equivalent | Description |
|---|---|---|
count | COUNT(*) or COUNT(column) | Count rows or distinct values |
sum | SUM(column) | Sum of numeric values |
avg | AVG(column) | Average of numeric values |
min | MIN(column) | Minimum value |
max | MAX(column) | Maximum value |
uniq | COUNT(DISTINCT column) | Count of unique values |
Metric Fields on Record Types
Metrics appear as top-level fields on each Cube’s Record type. Not all Cubes support all metrics — it depends on the Cube definition.The of Parameter
Metrics like sum, avg, min, max, and uniq require an of parameter that specifies which dimension to aggregate. The of value is an enum generated per Cube, following the dimension path naming convention.
Example: Total Buy Volume by DEX
count — Counting Rows
count without an of parameter counts the total rows in each group (equivalent to COUNT(*)):
uniq — Count Distinct
uniq maps to COUNT(DISTINCT column) in SQL. Use it to count unique values of a dimension:
selectWhere — HAVING-Style Filtering
selectWhere lets you filter on aggregation results, similar to SQL’s HAVING clause. It is applied after grouping and aggregation, allowing you to filter groups based on their metric values.
selectWhere supports the same numeric operators as IntFilter/FloatFilter:
| Operator | Description |
|---|---|
gt | Greater than |
gte | Greater than or equal |
lt | Less than |
lte | Less than or equal |
eq | Equal to |
ne | Not equal to |
Practical Example: Top Traders
Find the top 10 wallets by trade count for a token today, showing their total buy volume and unique trade count:Combining Multiple Metrics
You can select multiple metric fields in a single query:Metrics vs Pre-Aggregated Cubes
A common question: should I use metrics on DWD Cubes or query DWM/DWS Cubes directly?
| Approach | When to Use | Performance |
|---|---|---|
Metrics on DWD (e.g., DEXTrades.count) | Custom aggregations, ad-hoc groupings, flexible time windows | Slower — aggregates raw events at query time |
DWM Cubes (e.g., Pairs, Tokens) | Standard time-series analysis, OHLC charts, volume over time | Fast — reads pre-computed minute-level rollups |
DWS Cubes (e.g., TokenHolders, WalletTokenPnL) | Current snapshots, cumulative totals, leaderboards | Fastest — reads pre-aggregated summary data |
Decision Guide
I need a candlestick chart
I need a candlestick chart
Use Pairs (DWM). It already has pre-computed open/high/low/close/volume per minute. No need to aggregate DEXTrades yourself.
I need buy/sell counts per token
I need buy/sell counts per token
Use Tokens (DWM). It pre-aggregates trade counts, volumes, and unique traders per minute.
I need token holder rankings
I need token holder rankings
Use TokenHolders (DWS). Pre-computed latest balances per holder — much faster than aggregating BalanceUpdates.
I need custom per-DEX volume breakdown
I need custom per-DEX volume breakdown
Use DEXTrades with
count + sum(of: Trade_Buy_Amount) grouped by Trade.Dex.ProtocolName. This isn’t available as a pre-built Cube, so DWD metrics are the right choice.I need wallet PnL per token
I need wallet PnL per token
Use WalletTokenPnL (DWS). Pre-computed buy/sell volumes and trade counts per wallet-token pair.
Next Steps
Data Cubes
Explore all 25 Cubes and their field structures.
Query Examples
See real-world query examples with metrics and aggregation.

