Supported does not mean identical.

Discovers accessible projects through project, organization, or personal API-key scope.

Discovers accessible projects in the selected organization through a personal access token.

Each direct database is added explicitly as one project; there is no provider project-discovery API.

Current project metrics plus daily consumption history when the key scope and plan permit it.

Current filesystem utilization and daily API request categories are collected where permitted.

A direct PostgreSQL connection does not expose provider billing or usage APIs.

Current logical Postgres storage is collected from the project API.

The Management API value used by DatabaseMeter is filesystem disk use; direct read-only telemetry can measure the selected database.

A dedicated read-only role measures the connected database directly.

Daily CU-hours and current-period CPU-hours are retained with their original units and periods.

The current project endpoints do not provide compatible dedicated-compute consumption.

PostgreSQL telemetry is not treated as provider compute consumption.

The supported endpoint inventory does not expose Neon Console CPU or memory time series.

Hourly CPU-counter deltas and memory gauges are collected through the Metrics API beta when the token, plan, and response contract permit.

PostgreSQL workload statistics are not relabeled as host CPU or memory utilization.

Endpoint lifecycle state and configured autoscaling CU bounds are collected without waking computes.

The Metrics API can report CPU count, but DatabaseMeter does not infer a Supabase compute plan or lifecycle state from it.

A direct PostgreSQL connection does not expose provider compute lifecycle or sizing configuration.

Endpoint pooler configuration is available; provider disk-rate and pooler-utilization series are not exposed by the supported inventory endpoint.

Compatible cumulative disk counters and current pooler gauges are normalized through the Metrics API beta; resets and gaps remain unavailable.

Database telemetry retains PostgreSQL reads and sessions separately from host disk and provider-pooler metrics.

Available daily public and private network transfer values remain separately identifiable.

DatabaseMeter does not receive a compatible project byte total from its current endpoints.

A database connection cannot supply provider network-transfer billing totals.

Postgres storage and provider-native storage categories are retained; Neon is not treated as object storage.

Filesystem disk use is available, but object storage bytes are not supplied by the current endpoints.

Direct telemetry reports database, table, and index size—not provider or object storage.

A dedicated read-only PostgreSQL role supplies database and relation statistics.

A dedicated read-only PostgreSQL role supplies database-level and relation statistics.

A dedicated read-only PostgreSQL role supplies database and relation statistics.

Available when the extension and required statistics visibility are configured.

Managed-role delegation can limit cross-role statement visibility even when database telemetry is connected.

Available when pg_stat_statements is already configured and the role has statistics visibility; SQL text is excluded.

Qualified Launch/Scale planning ranges use versioned rules and stored compatible usage.

No project estimate is produced without compatible compute history and defensible organization allowance allocation.

No provider plan or billing rates are inferred from a PostgreSQL connection.

Provider collection and optional telemetry use protected, independently scheduled dispatchers.

Provider collection and optional telemetry use protected, independently scheduled dispatchers.

Direct read-only telemetry can run manually, hourly, every six hours, or daily.

Rules evaluate only when the required stored metric is available.

Rules evaluate only for the subset of stored metrics each project actually exposes.

Rules evaluate only against directly collected metrics that are actually available.