## Problem
Studio copy ties disk IO burst behavior to compute size thresholds and
says the IO budget "resets".
Burst eligibility isn't a single size cutoff
EBS burst credits refill continuously while disk usage runs below
baseline
Docs already use this framing (#50016)
Fixes PROD-665
## Solution
Three copy changes:
- `UnavailableChartBlock.tsx`: the burst balance chart placeholder no
longer names a size. It now describes sustained IO with no burst credit
pool
- `database-charts.ts`: the Disk IO Burst Balance tooltip describes the
EBS burst credit pool without referencing instance size
- `ResourceExhaustionWarningBanner.constants.ts`: the warning and
critical banners say the budget refills whenever disk usage runs below
baseline, instead of "resets"
## Review instructions
1. Read the diff. Copy changes only.
2. Optional: on a project with burstable disk IO, open Reports >
Database and hover the Disk IO Burst Balance chart title to see the new
tooltip.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which references
[WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md)
and the docs
[CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md)
guide
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
* Updated disk I/O chart messaging to explain that some compute types
sustain disk throughput without a burst credit pool to track.
* Clarified that disk I/O burst budgets refill when demand is at or
below baseline, and that throughput remains at baseline until the budget
refills.
* Updated the burst-balance chart tooltip to describe how compute uses
the EBS burst credit pool.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
This is a first draft at introducing semantic colours to our
Observability charts. This moves away from just random colours being
assigned to prop after prop. They're only scoped to the Database reports
right now, but if it flows nice, we can open it up to the other reports
too.
This also aims to tone down some of the harsher colours in our charts,
such as the orange which sometimes can look like a warning metric/prop.
| Before | After |
|--------|--------|
| <img width="839" height="336" alt="Screenshot 2026-06-10 at 09 14 56"
src="https://github.com/user-attachments/assets/222747c5-973b-4165-aa53-df7b93412ad3"
/> | <img width="950" height="341" alt="Screenshot 2026-09-14 at 18 14
47"
src="https://github.com/user-attachments/assets/836f3ddd-4a97-4064-b8cf-3a3b435417ac"
/> |
cc @supabase/design for additional thoughts.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added semantic chart color roles with light and dark theme variants
for consistent visualizations.
* Standardized colors and fills across database, networking, storage,
and connection charts.
* Maximum-value lines now use configured chart colors when available.
* Added chart palette reference and stress-test examples.
* Added stacked bar charts, customizable margins, and gradient-filled
line charts.
* Improved multi-series bar chart focus and date-range footer alignment.
* **Documentation**
* Documented the chart palette, theme variants, accessibility guidance,
and usage recommendations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
High Availability projects run Multigres and don't have Supavisor, so
the Shared Pooler (Supavisor) client connections chart in the database
report only ever rendered an "Unable to load data" error for them. This
hides the chart for HA projects, following the same pattern as the Disk
IO Burst Balance chart.
**Changed:**
- `supavisor-connections-active` chart is now hidden when
`project.high_availability` is true
**Added:**
- Unit tests covering the shared pooler chart's visibility for standard,
HA, and unentitled projects
## To test
- Open Reports → Database on a High Availability project – the Shared
Pooler (Supavisor) client connections chart should no longer appear
- Open the same report on a standard Pro project – the chart should
still render as before
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* The active connection chart is now hidden for High Availability
projects and projects without the database entitlement, preventing empty
or unavailable data from being displayed.
* **Tests**
* Added coverage to verify the chart appears only for eligible standard
projects.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
The "Dedicated Pooler Client Connections" chart on the Database
observability page labels its series `pgbouncer` and links to PgBouncer
limits docs. High Availability projects run Multigres, whose dedicated
pooler is multipooler, so that copy was misleading. This swaps the copy
for HA projects and drops the docs link until multipooler docs exist
(per the ticket, disabling the link for now is fine).
**Changed:**
- HA projects: legend label `pgbouncer` → `multipooler`, series tooltip
→ "Multipooler connections"
- HA projects: the info icon shows a "docs coming soon" tooltip instead
of linking to the compute-and-disk limits docs
- Non-HA projects are unchanged
**Added:**
- Unit test for `getReportAttributesV2` covering both the PgBouncer and
multipooler branches
Out of scope (flagging for follow-up): the "Max pooler connections"
reference line still uses the PgBouncer value on HA projects, and the
Supavisor chart still renders for HA projects.
Addresses
https://linear.app/supabase/issue/MUL-1364/database-dashboard-update-dedicated-poolers-copy
## To test
- On a High Availability project, open Observability → Database and find
"Dedicated Pooler Client Connections"
- Legend and hover tooltip should say `multipooler`; the info icon
should show a tooltip ending in "(docs coming soon)" with no link
- On a non-HA project, the chart should be unchanged: `pgbouncer` legend
and the info icon links to the compute-and-disk docs
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- High Availability projects now display dedicated connection pooler
charts with multipooler-specific labels and guidance.
- Standard projects continue to show PgBouncer information and
documentation links.
- High Availability charts include a tooltip indicating that
documentation is coming soon.
- **Tests**
- Added coverage to verify the correct chart labels, tooltips, and
documentation behavior for both project types.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Hides the Disk IO Burst Balance chart on the Database observability page
for High Availability projects. Their volumes have no burst credit pool,
so the panel had nothing to load and rendered "Unable to load data for
Disk IO Burst Balance".
**Changed:**
- `getReportAttributesV2` now also requires
`!resolveHighAvailability(project)` before showing the
`disk-io-burst-balance` chart – the existing feature flag and
`hasBurstableIO` gating are unchanged for non-HA projects
**Added:**
- Unit tests covering the chart's visibility across HA / flag / compute
size combinations
## To test
- On a High Availability project with the `showDiskIOBurstBalanceChart`
flag on, open `/project/[ref]/observability/database` – the Disk IO
Burst Balance panel should no longer render
- On a non-HA project with a burstable compute size (e.g. micro) and the
flag on, the panel should still render as before
Addresses
https://linear.app/supabase/issue/MUL-1347/remove-panel-from-database-dashboard
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Hid the Disk I/O Burst Balance chart for High Availability projects,
where no burst-credit data is available.
* Continued hiding the chart when burst balancing is unsupported or
disabled.
* **Tests**
* Added coverage for eligible projects and scenarios where the chart
should remain hidden.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Context
Realised that tooltips were not showing up for supavisor charts in
database reports - just needed to flip a boolean
Although - i don't have any projects with supavisor connections data
(even on prod) so I can't visually verify this atm
Also fixes a small issue in which docs url for the chart wasn't showing
if the chart had no data, e.g:
<img width="996" height="311" alt="image"
src="https://github.com/user-attachments/assets/926febe4-9e3d-4975-9278-e7582d6ae12d"
/>
Should have docs button like this
<img width="949" height="351" alt="image"
src="https://github.com/user-attachments/assets/7561c1c5-94ae-405b-bd54-6bc94be0dd0a"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Enabled tooltips for the “Shared Pooler (Supavisor) client
connections” chart so the metric can be inspected directly.
* **UI Improvements**
* Adjusted the tooltip positioning in the chart header for clearer
readability.
* When charts have no data, the “Learn more”/documentation link now
follows the provided docs URL.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
## Problem
The Memory usage chart in the database report showed RAM used, cache,
free, and total, but did not include swap. Swap activity is a meaningful
signal of memory pressure and was only visible in a hidden standalone
chart.
## Fix
Added `swap_usage` (from the `infra-monitoring` provider) as an
additional series in the `ram-usage` Memory chart. The series uses
`omitFromTotal: true` so it does not inflate the stacked total, and
carries the same tooltip text as the hidden standalone swap chart. The
standalone `swap-usage` chart remains hidden as before.
## How to test
- Open the database report for a project on any compute size.
- Navigate to the Memory usage chart.
- Confirm a "Swap" series appears in the legend and renders data
alongside Used, Cache + Buffers, and Free.
- Hover a data point and confirm the tooltip shows a Swap value with the
memory-pressure description.
- Confirm the Swap value does not contribute to the stacked total.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a "Swap" metric to the RAM usage chart in reports, displaying
swap memory usage information with an updated tooltip.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
The CPU usage chart rendered every bar as nearly full (looked like ~100%
CPU) even when actual usage was 0.13%. The header value and tooltip were
correct (0.13%); only the bars were wrong.
## Cause
The chart used `normalizeVisibleStackToPercent: true`, which rescales
the visible stacked series so they always sum to 100% of the bar height.
The CPU series are already absolute percentages, so normalizing
stretched a real 0.13% to fill the whole bar. The `Idle` series existed
only to pad the stack to 100%.
## Fix
- Remove `normalizeVisibleStackToPercent` from the CPU chart so series
render at absolute values against the fixed 0-100% Y axis.
- Drop the `Idle` series (no longer needed to pad the stack, and we
don't want to show it).
- Revert the unused `hideFromLegend` plumbing from the earlier attempt.
Result: low CPU usage now renders as a near-empty bar, accurately
reflecting the real value.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Updated CPU usage chart in database reports to display a focused set
of CPU metrics.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
## Problem
Sustained memory overcommitment is one of the failure patterns that most
often leads to databases being killed when the system runs out of
memory. Today the database report only shows used memory against total
RAM, which hides the kernel's commit accounting: a project can sit far
above its commit limit (RAM plus swap, adjusted by the overcommit ratio)
and the dashboard gives no signal until something breaks.
A combined chart with swap, overcommitment, and main memory was
considered too dense, and a standalone swap chart was not useful enough
on its own.
Linear: [DEBUG-119](https://linear.app/supabase/issue/DEBUG-119)
## Fix
Adds a separate "Memory commitment" chart between the existing memory
usage and swap charts. It plots `ram_commit_used` (Committed_AS) as the
main series with `ram_commit_limit` (CommitLimit) as the max-value
threshold line, so values approaching or crossing the limit are visually
obvious. Backend support for the two new metric attributes ships in
supabase/platform#33321.
## How to test
- Wait for the platform PR (supabase/platform#33321) to deploy so the
two new attributes are accepted by the infra monitoring endpoint.
- Open any project, navigate to Database -> Reports.
- Confirm the new "Memory commitment" chart appears between "Memory
usage" and "Swap usage".
- Confirm the chart shows two series: the committed memory bars/area and
a max line for the commit limit.
- Hover the legend and the chart to confirm the tooltips read clearly.
- Confirm the time range selector and chart sync (`syncId:
'database-reports'`) keep this chart aligned with the others.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added comprehensive guide for interpreting memory commitment patterns
in telemetry reports, including component breakdown, chart pattern
guidance, and actionable recommendations.
* **New Features**
* Added memory commitment chart to database observability dashboard,
displaying RAM commitment usage and limits.
* Extended monitoring API to support new RAM commitment metrics.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
## Problem
The Swap usage chart in the database report (Observability > Database)
displays inaccurate data.
## Fix
Set the swap-usage chart's `hide` flag to `true` in
[`database-charts.ts`](apps/studio/data/reports/database-charts.ts) so
it no longer renders. The chart definition is kept so it can be
re-enabled once the underlying metric is reliable.
## Test plan
- [ ] Open Observability > Database report and confirm the Swap usage
chart is no longer shown
- [ ] Confirm other charts (Memory, CPU, Disk, etc.) continue to render
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Corrected the visibility of the swap usage chart in reports—it is now
properly hidden from display.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46465?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
## Problem
On 4XL and larger compute sizes, Supabase disk IO is sustained rather
than burst-budget based. Baseline equals max, so there is no extra burst
balance to track (the instance can still be throttled if it hits its
configured IOPS or throughput limit, but that is unrelated to a burst
credit pool). The "Disk IO Burst Balance" / "Disk IO % Remaining" /
"Disk IO % Consumed" charts in custom reports are therefore meaningless
on 4XL+, yet they are currently still offered in the picker and rendered
as empty/misleading charts.
Custom reports persist their layout, so a report created when a project
was on a smaller compute and later upgraded to 4XL+ can still contain a
saved burst chart that we need to handle gracefully.
## Fix
- Add a shared \`hasBurstableIO(infra_compute_size)\` helper in
\`DiskManagement.utils.ts\` (replaces the local
\`BURSTABLE_IO_VARIANTS\` set previously defined inline in
\`database-charts.ts\`).
- Filter \`disk_io_budget\` and \`disk_io_consumption\` out of the
custom report chart picker (\`MetricOptions\`) when the project is on a
non-burstable compute size.
- In \`ReportBlock\`, detect saved burst charts on a 4XL+ project and
render a new \`UnavailableChartBlock\` that explains the chart no longer
applies and can be removed.
- The database observability burst balance chart already gated on
\`hasBurstableIO\`; updated to use the shared helper.
- Infrastructure activity page already has equivalent handling via the
dedicated-IO admonition, so no change needed there.
Linear: FDBKPRI-1404
## Test plan
- [ ] On a project below 4XL, the custom report picker still lists "Disk
IO % Remaining" and "Disk IO % Consumed", and they render normally
- [ ] On a 4XL+ project, neither metric appears in the picker
- [ ] Open an existing custom report that contains a saved burst balance
chart on a 4XL+ project, and confirm the placeholder block renders with
a clear explanation and a remove action
- [ ] Database observability page on 4XL+: the burst balance chart
remains hidden, all other charts render
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Disk IO metrics are now filtered based on your project’s compute size
so only relevant charts appear.
* Metrics tied to burstable IO are hidden when the current instance does
not support burstable IO; deprecated metrics remain excluded.
* When a disk IO chart isn’t available for your instance, the UI shows
an explanatory unavailable-chart block with text about burst-balance
limits for very large instances and optional actions to remove the
unavailable chart.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46327?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Fixes [DEBUG-94](https://linear.app/supabase/issue/DEBUG-94)
## Summary
- **Min MB units**: Added \`formatBytesMinMB\` helper that always
formats byte values in at least MB. Applied to RAM and swap y-axis tick
formatters, tooltips, and chart headers.
- **Swap chart scale**: Every Supabase compute instance is provisioned
with **1 GB of swap regardless of size** (per
[docs](https://supabase.com/docs/guides/troubleshooting/memory-and-swap-usage-explained-aPNgm0)),
so the swap y-axis always shows at least 0 to 1 GB. Low swap usage no
longer fills the full chart height. Removed the show/hide limit toggle
since the limit is implicit in the y-axis scale.
- **Swap units in header/tooltip**: Fixed all three formatters (initial
header, hover-sync header, tooltip) to use \`formatBytesMinMB\` for swap
so the value always shows a unit like "2.00 MB".
- **Reference-line defensive fix**: Added a \`customValue\` fallback in
\`useAttributeQueries\` so future reference-line attributes that use
\`customValue\` instead of \`value\` are not silently overwritten to 0.
## Test plan
- [ ] Open DB Reports and verify RAM/Swap y-axis labels show MB (or GB
for large values), never KB or bytes
- [ ] Hover a bar in the swap chart and verify tooltip and header show
the same value with a unit (e.g. "2.00 MB")
- [ ] With low or zero swap usage, the chart bars are flat and the
y-axis goes 0 to 1 GB
- [ ] CPU chart limit toggle still renders at 100% (regression check on
the \`useAttributeQueries\` fallback change)
🤖 Generated with [Claude Code](https://claude.ai/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
When users hit a disk IO exhaustion notification, they open the Database
Observability report and find IOPS and throughput charts, but no view of
the metric that actually fired the warning: the EBS burst credit
balance. That signal is currently only available behind Custom Reports,
so the warning feels disconnected from the visible data.
> "The Dashboard actually shows them their burst budget, not their
normal disk usage. It leads to a lot of confusion." — support
> "Customers may receive an 'exhausting multiple resources' warning and
it's confusing because all the charts are 'fine', but it's the burst
credits exhaustion that fails them." — Maksym
Reported in [Linear
DEBUG-60](https://linear.app/supabase/issue/DEBUG-60).
## Fix
Add a clearly-labeled "Disk IO Burst Balance" chart to
[getReportAttributesV2](apps/studio/data/reports/database-charts.ts)
plotting `disk_io_budget` (% remaining) on a 0-100 axis. Tooltip and
titleTooltip explain the 5 MB/s throttle floor so users can correlate
this chart with the exhaustion banner copy (also being updated in
[supabase#45514](https://github.com/supabase/supabase/pull/45514)).
The chart is hidden for compute variants that have dedicated I/O
resources (4XL and above) since the burst credit pool does not apply
there. Burstable variants (nano through 2XL) see the chart inline next
to the existing IOPS and throughput charts.
DEBUG-61 ("replace Disk IO Usage % chart with disk throughput") was
already addressed in the V2 migration (the report only renders
`disk-iops` and `disk-throughput`; the old burst-percentage chart is
gone). I'll close that issue as completed once this lands.
## Test plan
- [ ] Visit `/project/{ref}/observability/database` on a project running
`nano`/`micro`/`small`/`medium`/`large`/`xlarge`/`2xlarge` compute.
Confirm the new "Disk IO Burst Balance" chart appears between throughput
and connections.
- [ ] On a project running `4xlarge` or larger compute, confirm the
chart is hidden (chart is omitted by `hide: !hasBurstableIO`).
- [ ] Hover the chart and a data point. Confirm the title tooltip and
inline attribute tooltip both surface the 5 MB/s throttle behaviour.
- [ ] Series renders 0-100 on the Y-axis.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a Disk IO Burst Balance chart to monitor remaining burst
credits; displays percentage (0–100%) with tooltip referencing baseline
throughput. Shown only for supported compute variants and when the
feature flag is enabled.
* **Bug Fixes / UI Improvements**
* Improved chart header tooltip presentation: uses a unified tooltip,
includes inline docs links when available, and avoids duplicate docs
icons.
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45516)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
## Problem
Recent database report PRs introduced `(value: any)` type annotations in
recharts `tickFormatter` callbacks, pushing the
`@typescript-eslint/no-explicit-any` ESLint ratchet from baseline 1014
to 1017 and blocking all PR merges.
## Fix
Replace `(value: any)` with `(value: number)` in all affected
`tickFormatter` callbacks across the three flagged files. Recharts
always passes a number to tick formatters, so this is a safe and
accurate type.
## How to test
- Run `pnpm lint --filter=studio` and confirm no new
`@typescript-eslint/no-explicit-any` violations appear in the three
changed files
- Check the ESLint ratchet count is back at or below baseline 1014
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Improved type safety for Y‑axis tick formatters across observability
charts (Memory, Swap, Network throughput, Disk IOPS/throughput/usage,
Replication Lag), ensuring tick values are treated as numeric for more
consistent chart rendering and reliability.
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45794)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
## Problem
The Database report in Observability has no view of network traffic.
Inbound/outbound throughput is useful for spotting saturation, large
unexpected egress, or correlating spikes with disk I/O.
Closes
[FE-3193](https://linear.app/supabase/issue/FE-3193/add-network-in-and-out-charts).
## Fix
Add a new \`network-throughput\` chart entry to
\`getReportAttributesV2\` in
[apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts),
placed right before \`disk-iops\`. Uses the existing
\`network_receive_bytes\` and \`network_transmit_bytes\`
infra-monitoring attributes (series already exist, no backend work
needed). Pattern mirrors the \`disk-throughput\` chart: bytes-per-second
Y-axis, \`stackedAreaLine\` default, same \`syncId\`.
\`showMaxValue\` is \`false\` because there is no provisioned network
max to render as a reference line.
## Test plan
- [ ] Open \`/project/<ref>/observability/database\` and confirm a
"Network throughput" chart renders with two series (Network in / Network
out) and a \`bytes/s\` Y-axis.
- [ ] Switch the date range and confirm the chart respects it
(auto-wired via \`REPORT_ATTRIBUTES.flatMap\`).
- [ ] Use the global refresh button and confirm both series invalidate
with the rest.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a network throughput chart that visualizes inbound and outbound
network throughput metrics with real-time speed data visualization.
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45747)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
## Problem
The Max IOPS reference line in the Database Observability report
displays the provisioned disk IOPS, but its tooltip claims it shows the
"Maximum IOPS for your current compute size". The real effective ceiling
is `min(compute IOPS limit, provisioned disk IOPS)`. Users who upgrade
their disk IOPS without upgrading compute see an inflated number and may
draw incorrect conclusions about their IO headroom.
Reported in [Linear
DEBUG-63](https://linear.app/supabase/issue/DEBUG-63) (originally
[FE-2856](https://linear.app/supabase/issue/FE-2856)).
## Fix
In
[apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts),
use the existing `mapComputeSizeNameToAddonVariantId` +
`COMPUTE_MAX_IOPS` lookup (already used in DiskManagement) to compute
the effective ceiling and pass it as the `disk_iops_max` reference line
value. Tooltip rewritten to match.
```ts
const provisionedDiskIops = diskConfig?.attributes?.iops
const computeIopsLimit =
COMPUTE_MAX_IOPS[mapComputeSizeNameToAddonVariantId(project?.infra_compute_size)]
const effectiveMaxIops =
typeof provisionedDiskIops === 'number' && typeof computeIopsLimit === 'number'
? Math.min(provisionedDiskIops, computeIopsLimit)
: provisionedDiskIops
```
## Test plan
- [ ] On a project where compute IOPS limit < provisioned disk IOPS
(e.g. Micro compute with upgraded disk), confirm the Max IOPS reference
line on `/project/{ref}/observability/database` reflects the compute
limit, not the disk IOPS.
- [ ] On a project where provisioned disk IOPS < compute IOPS limit,
confirm the reference line still shows the disk IOPS.
- [ ] Hover the line and confirm the tooltip reads "Effective maximum
IOPS for your current compute and disk configuration..."
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Bug Fixes**
* Enhanced IOPS limit calculations in database reports to account for
both compute size and disk provisioning constraints, resulting in more
accurate Max IOPS reference values. Improved chart tooltips to better
reflect the effective combined compute and disk IOPS constraints.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This PR migrates the whole monorepo to use Tailwind v4:
- Removed `@tailwindcss/container-queries` plugin since it's included by
default in v4,
- Bump all instances of Tailwind to v4. Made minimal changes to the
shared config to remove non-supported features (`alpha` mentions),
- Migrate all apps to be compatible with v4 configs,
- Fix the `typography.css` import in 3 apps,
- Add missing rules which were included by default in v3,
- Run `pnpm dlx @tailwindcss/upgrade` on all apps, which renames a lot
of classes
- Rename all misnamed classes according to
https://tailwindcss.com/docs/upgrade-guide#renamed-utilities in all
apps.
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
## Problem
The disk throughput chart on the database observability report was gated
to Team plan and above. This prevented Free and Pro tier users from
seeing disk throughput data, which is a useful self-debugging aid when
hitting DiskIO-related resource exhaustion, especially on smaller
instances where baseline throughput limits are a major constraint.
The gate was originally introduced to reduce load on the metrics
infrastructure while observability queries were being scaled. That
constraint no longer applies.
## Fix
Remove the `entitlement` and `requiredPlan` fields from the
`disk-throughput` chart config in
`apps/studio/data/reports/database-charts.ts`. The rendering logic in
the database observability page only shows the upsell prompt when
`chart.entitlement` is set, so removing it makes the chart render
unconditionally for all tiers.
## How to test
- Open the database observability report at
`/project/<ref>/observability/database` on a Free or Pro project
- Confirm the Disk Throughput chart is visible and showing data (not an
upsell card)
- Confirm the chart still works correctly on a Team or Enterprise
project
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Removed plan-based access restrictions from disk-throughput metrics,
making them available to all users.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Changes
- Replaces plan ID-based chart gating with entitlement-based checks
across all observability pages (database, auth, realtime,
edge-functions)
- Adds requiredPlan display field so the upsell shows the correct target
plan (e.g. "Upgrade to Team" for disk throughput, not just "Upgrade")
- Decouples database-charts.ts from Organization Plan, now accepts
pre-computed entitlement flags instead
### Note on `requiredPlan`
The entitlement system currently tells us whether a user has access, but
not what plan they need to get access. `requiredPlan` is a frontend-only
display hint. Ideally the backend entitlement response would include a
minimumPlan field so we can remove this hardcoded mapping. For now, this
is a pragmatic workaround to avoid misleading upsell copy (e.g. a Free
user seeing "Upgrade" for a Team-only feature and landing on Pro).
## Testing
### Database
- Head to `/project/_/observability/database` with an Org on the Free
Plan and assert that the Disk throughput is gated.
<img width="1402" height="682" alt="image"
src="https://github.com/user-attachments/assets/b783d866-774d-44dc-88d1-797d26502f02"
/>
### Auth
- Head to `/project/_/observability/auth` with an Org on the Free Plan
and assert that the following metrics are gated:
<img width="1402" height="682" alt="image"
src="https://github.com/user-attachments/assets/cb062dd7-5864-4e40-a11f-ad6be1f7fd41"
/>
### Edge Functions
- Head to `/project/_/observability/edge-functions` with an Org on the
Free Plan and assert that the following metrics are gated:
<img width="1402" height="320" alt="image"
src="https://github.com/user-attachments/assets/517b5483-4575-493c-9401-2c67ac9e684c"
/>
### Realtime
- Head to `/project/_/observability/realtime` with an Org on the Free
Plan and assert that the following metrics are gated:
<img width="1402" height="722" alt="image"
src="https://github.com/user-attachments/assets/0c2757a2-8482-43f4-a65c-c0dde3d878c7"
/>
The Y axis domain/range was being calculated incorrectly.
Testing this is a bit painful. You need to:
- using tweak-extension or similar overwrite the API response for the
IOPS chart and add a really big value
- reload the page
- the Y axis should adapt to that really big value even if it goes over
the disk max iops
See screenshots below
## before
- big data point wouldn't change the chart range
- Y Axis max is 6k even tho we have a data point over 20k
<img width="1204" height="714" alt="CleanShot 2026-02-25 at 18 47 14@2x"
src="https://github.com/user-attachments/assets/881aff6e-22a2-408d-b2c4-5a27f3fda386"
/>
## after
- the Y axis shows the correct range
<img width="932" height="786" alt="CleanShot 2026-02-25 at 18 47 57@2x"
src="https://github.com/user-attachments/assets/6247c66e-4b3e-49e9-9f6b-086086913fab"
/>
* support total percentage normalization and show idle time in cpu usage chart
* pretier
* improve test
* clarify in comment why new prop is necessary
* fix type error int est
* refactor to use max value instead of idle property, add more tests
* cleanup composed chart
* prettier
* fix tests
* react improvements
* remove unused stacking properties
* remove rest property references as it wont be used
* fix comment and max cpu desc
* test the resolvehighlightedvalue function
* undo unnecessary composedcharthandler change
* remove unnecessary comment
* minor db charts percentage formatting fixes
* move format check
* fix issue with conflict resolution
* Update Supabase docs URLs to use env variable
Co-authored-by: a <a@alaisteryoung.com>
* Refactor: Use DOCS_URL constant for documentation links
This change centralizes documentation links using a new DOCS_URL constant, improving maintainability and consistency.
Co-authored-by: a <a@alaisteryoung.com>
* Refactor: Use DOCS_URL constant for all documentation links
This change replaces hardcoded documentation URLs with a centralized constant, improving maintainability and consistency.
Co-authored-by: a <a@alaisteryoung.com>
* replace more instances
* ci: Autofix updates from GitHub workflow
* remaining instances
* fix duplicate useRouter
---------
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: alaister <10985857+alaister@users.noreply.github.com>
* chore: add docs for new db reports charts
* chore: fix linting issues
* move db reports docs to telemetry section
* add more info to reports docs
* fix lint suggestions
* update reports
* update latest links and chart screenshots
* advanced telemetry
* update db section
Lukas Bernert
