The Metrics tab (src/scenes/Editor/Metrics/, persisted as BufferType.METRICS with metricsViewState on the Buffer) is conceptually a sibling of notebooks: a grid of time-series charts persisted on a Buffer, with refresh. We want to fold Metrics into Notebooks so there's a single dashboard surface. Explicitly future / not urgent — don't block notebook work on it.
What Metrics is today
- Buffer carries
metricsViewState (src/store/buffers.ts:50-57): global dateFrom/dateTo, refreshRate (AUTO/OFF/1s/5s/10s/30s/1m), sampleBy, viewMode, and metrics: Metric[].
- Each
Metric is a predefined widget (not arbitrary SQL): metricType + tableId + color/position. The widget set lives in src/scenes/Editor/Metrics/widgets/ (WAL throughput/latency, row throughput, write amplification, avg txn size); each widget's getQuery() builds SQL from tableId + sampleBy + time range (src/scenes/Editor/Metrics/types.ts).
- Charts render with uPlot (
createUplotOptions.ts, graph.tsx) under a global date-range picker, refresh rate, and sampleBy.
How that differs from notebooks
Notebooks use echarts (src/scenes/Editor/Notebook/CellChart/), arbitrary SQL per cell, and per-cell auto-refresh (no global date range / sampleBy); metrics are MCP-invisible while notebooks are MCP-controllable.
Prerequisite
We don't have a global (notebook-level) time-range or refresh rate today — notebooks only have per-cell auto-refresh, whereas Metrics is built entirely around global date-range + refresh + sampleBy controls. When these global controls are added (notebook-level time-range, and the notebook-level refresh rate from #577), the migration becomes feasible.
Migration shape
A metrics dashboard becomes a notebook of chart cells, the predefined widgets become SQL chart cells seeded from the widget query templates, and the global date-range / refresh / sampleBy become notebook-level controls. Needs a one-time data migration of persisted metricsViewState → notebookViewState (and BufferType.METRICS → NOTEBOOK).
The Metrics tab (
src/scenes/Editor/Metrics/, persisted asBufferType.METRICSwithmetricsViewStateon the Buffer) is conceptually a sibling of notebooks: a grid of time-series charts persisted on a Buffer, with refresh. We want to fold Metrics into Notebooks so there's a single dashboard surface. Explicitly future / not urgent — don't block notebook work on it.What Metrics is today
metricsViewState(src/store/buffers.ts:50-57): globaldateFrom/dateTo,refreshRate(AUTO/OFF/1s/5s/10s/30s/1m),sampleBy,viewMode, andmetrics: Metric[].Metricis a predefined widget (not arbitrary SQL):metricType+tableId+ color/position. The widget set lives insrc/scenes/Editor/Metrics/widgets/(WAL throughput/latency, row throughput, write amplification, avg txn size); each widget'sgetQuery()builds SQL from tableId + sampleBy + time range (src/scenes/Editor/Metrics/types.ts).createUplotOptions.ts,graph.tsx) under a global date-range picker, refresh rate, and sampleBy.How that differs from notebooks
Notebooks use echarts (
src/scenes/Editor/Notebook/CellChart/), arbitrary SQL per cell, and per-cell auto-refresh (no global date range / sampleBy); metrics are MCP-invisible while notebooks are MCP-controllable.Prerequisite
We don't have a global (notebook-level) time-range or refresh rate today — notebooks only have per-cell auto-refresh, whereas Metrics is built entirely around global date-range + refresh + sampleBy controls. When these global controls are added (notebook-level time-range, and the notebook-level refresh rate from #577), the migration becomes feasible.
Migration shape
A metrics dashboard becomes a notebook of chart cells, the predefined widgets become SQL chart cells seeded from the widget query templates, and the global date-range / refresh / sampleBy become notebook-level controls. Needs a one-time data migration of persisted
metricsViewState→notebookViewState(andBufferType.METRICS→NOTEBOOK).