stillship

Supabase

10 releases trackedchecked dailyShipping actively
RSS feed ↗
Release signals: ships every ~16 days · last release today · activity: active · 0% breaking changes in recent releases
2026-12-01

Status page moves to incident.io Oct 8, 2026 Improvement status.supabase.com now runs on incident.io's status page. The URL is unchanged. Email subscribers were resubscribed automatically. If you subscribed through SMS, Slack, webhook, or RSS, those subscriptions did not carry over. Resubscribe at status.supabase.com . The new platform supports only Email, RSS, and Slack, so SMS and webhook notifications are no longer available. Email subscribers can now subscribe to the specific Products and Regions that matter most to them, so they only hear about incidents that affect them. Website Scoped personal access tokens are now generally available Oct 6, 2026 New Feature Scoped personal access tokens (PATs) are now available to everyone. You can limit a token to specific projects or organizations and grant only the permissions it needs. You pick a token's access when you create it # On your access tokens page , choose: Resources: selected projects in one organization, or all projects in selected organizations. Permissions: read or read-write per capability, such as projects, database, auth, or storage. Expiry: a preset or a custom date up to one year out. A review step shows the access you're granting and a risk level. You see the token value only when you create it. You can't change a token's access later. To change it, delete the token and create a new one. A token never has more access than you do. Every request checks your current role. When you lose access, so does the token. Scoped tokens work with the Management API, MCP server, and CLI # Management API: all /v1 and /v2 endpoints. A 403 lists the permissions the token lacks in a missing_permissions array. Supabase MCP server: each tool checks the token's permissions. The token's detail view in the dashboard lists the tools it can call. Supabase CLI: pass the token with supabase login --token or set SUPABASE_ACCESS_TOKEN . The browser flow for supabase login still creates an account-level token. supabase whoami doesn't work with project- or organization-scoped tokens. Some access needs a specific permission. Revealing secret API keys needs API Key Secrets. SQL runs read-only unless the token has Database read-write. The personal access tokens docs map each permission to its endpoints and MCP tools. Your existing tokens keep working # We aren't revoking anything. Every existing token works until it expires or you delete it. You can still create an account-level token with "Create legacy token". A leaked scoped token exposes far less. GitHub secret scanning detects both kinds. Replace your account-level tokens with scoped ones # Swap each account-level token for a scoped token that has only the access its integration needs. If you're missing a permission or the form doesn't fit your workflow, tell us in the GitHub Discussion for this entry. Platform Security CLI AI Organization invites support the No access role Oct 5, 2026 Improvement Admins on Team and Enterprise plans can now invite organization members with the No access role directly from the invite flow and can switch an existing member to it. Previously, the lowest available organization role was Read-only, which still granted visibility into every project in the organization. With No access, new members start with no project access; admins grant access to individual projects as needed. No access can only be assigned at the organization level, not per project, so project access is still layered on top of it one project at a time. Members with the No access role now also show up in the organization's member list - they were previously filtered out. See Access control for the full set of organization and project roles. Platform Studio Security 2026 2026 Deprecation Framework adapters in @supabase/server are deprecated

A software release for Supabase, a cloud-based platform, includes improvements to its status page, support for scoped personal access tokens, and changes to its access control and security features.

2026-09-25

Logs usage-based pricing

Supabase's logs usage-based pricing allows users to pay only for the actual logs they store, reducing costs for companies with varying data needs.

2026-09-25

PostgreSQL 15.19 / 17.11 minor release — action may be required for ltree, pgcrypto, btree_gist, and custom operators Sep 25, 2026 Breaking Change [data-ch-theme="supabase"] { --ch-t-colorScheme: var(--ch-0);--ch-t-foreground: var(--ch-4);--ch-t-background: var(--ch-16);--ch-t-editor-background: var(--ch-16);--ch-t-editor-foreground: var(--ch-4);--ch-t-editor-rangeHighlightBackground: var(--ch-19);--ch-t-editor-infoForeground: var(--ch-18);--ch-t-editor-selectionBackground: var(--ch-17);--ch-t-tab-activeBackground: var(--ch-16);--ch-t-tab-activeForeground: var(--ch-4);--ch-t-tab-inactiveBackground: var(--ch-21);--ch-t-tab-inactiveForeground: var(--ch-15);--ch-t-tab-border: var(--ch-22);--ch-t-tab-activeBorder: var(--ch-16);--ch-t-editorGroupHeader-tabsBackground: var(--ch-21);--ch-t-editorLineNumber-foreground: var(--ch-20);--ch-t-input-foreground: var(--ch-4);--ch-t-sideBar-foreground: var(--ch-4);--ch-t-list-hoverBackground: var(--ch-25);--ch-t-list-hoverForeground: var(--ch-4); } What changed # We are rolling out the PostgreSQL 15.19 / 17.11 minor release (from 15.14 / 17.6). It bundles five upstream security cycles and closes 44 CVEs . Four changes may require action, depending on how you use your database: ltree indexes may need reindexing — a case-folding fix on multibyte/ICU databases, plus an integer-overflow fix for very deep ltree values (any encoding). pgcrypto stops decrypting legacy-cipher PGP data (CVE-2026-14663) — data encrypted with cipher-algo=bf / blowfish / cast5 was effectively stored unencrypted and fails to decrypt by default after the upgrade. btree_gist indexes on float columns that may contain NaN need reindexing. Custom operators with non-built-in selectivity estimators (CVE-2026-2004) — recreating them (dump/restore, branching) now requires superuser. If none of the detection queries below return rows for your project, no action is needed. Why we made this change # This is an upstream PostgreSQL minor release. Staying current closes 44 CVEs (including several rated High) and picks up correctness fixes in the ltree and btree_gist extensions. Who is affected # 1. ltree indexes # Case-folding (multibyte/ICU) # After upgrading, indexes on ltree columns built under the previous version can silently return incomplete results on databases using a multibyte encoding (such as UTF-8) or a non- libc collation provider (ICU or builtin). Check whether your database is affected: _ 10 select _ 10 pg_encoding_to_char(encoding) as encoding, _ 10 pg_encoding_max_length(encoding) as max_bytes_per_char, -- 1 = single-byte, >1 = multibyte _ 10 datlocprovider as collation_provider, -- 'c' libc, 'i' icu, 'b' builtin _ 10 (pg_encoding_max_length(encoding) > 1 or datlocprovider != 'c') as reindex_required _ 10 from pg_database _ 10 where datname = current_database(); If reindex_required is true , find the affected indexes: _ 14 select distinct _ 14 n.nspname as schema_name, _ 14 cls.relname as table_name, _ 14 ic.relname as index_name _ 14 from pg_index idx _ 14 join pg_class ic on idx.indexrelid = ic.oid _ 14 join pg_class cls on idx.indrelid = cls.oid _ 14 join pg_namespace n on ic.relnamespace = n.oid _ 14 join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true _ 14 join pg_opclass oc on oc.oid = k.opclass _ 14 join pg_type ty on ty.oid = oc.opcintype _ 14 where _ 14 k.pos <= idx.indnkeyatts -- key columns only, excludes INCLUDE _ 14 and ty.typname in ('ltree', '_ltree'); Integer overflow (any encoding) # This release also fixes an integer overflow in ltree comparisons: values with more than about 14,653 labels could compare incorrectly, which can corrupt B-tree indexes built over them, regardless of your database encoding. This query lists only the B-tree indexes that actually contain such values (an empty result means no action is needed): _ 35 select s.schema_name || '.' || s.index_name as index_to_reindex _ 35 from ( _ 35 select _ 35 n.nspname as schema_name, _ 35 c.relname as table_name, _ 35 ic.relname as index_name, _ 35 min(pg_get_expr(i.indpred, i.indrelid)) as pred, -- partial-index predicate, if any _ 35 string_agg('nlevel(' || pg_get_indexdef(i.indexrelid, k.pos::int, true) || ') > 14653', ' or ') as keys_cond _ 35 from pg_index i _ 35 join pg_class ic on ic.oid = i.indexrelid _ 35 join pg_class c on c.oid = i.indrelid _ 35 join pg_namespace n on n.oid = c.relnamespace _ 35 join pg_am am on am.oid = ic.relam _ 35 join lateral generate_series(1, i.indnkeyatts) as k(pos) on true _ 35 join pg_attribute ia on ia.attrelid = i.indexrelid and ia.attnum = k.pos _ 35 join pg_type t on t.oid = ia.atttypid _ 35 where am.amname = 'btree' _ 35 and t.typname = 'ltree' _ 35 and n.nspname not in ('pg_catalog', 'information_schema') _ 35 group by n.nspname, c.relname, ic.relname _ 35 ) s _ 35 where (xpath( _ 35 '/row/cnt/text()', _ 35 query_to_xml( _ 35 format('select count(*) as cnt from %I.%I where %s(%s)', _ 35 s.schema_name, _ 35 s.table_name, _ 35 case when s.pred is not null then '(' || s.pred || ') and ' else '' end, _ 35 s.keys_cond), _ 35 false, _ 35 true, _ 35 '' _ 35 ) _ 35 ))[1]::text::bigint > 0 _ 35 order by 1; 2. pgcrypto legacy ciphers (CVE-2026-14663) # If you call pgp_sym_encrypt / pgp_pub_encrypt (or their _bytea variants) with cipher-algo=bf , cipher-algo=blowfish , or cipher-algo=cast5 , that data was effectively stored unencrypted — decryption succeeds even with the wrong key. The default cipher (AES) and 3des are not affected. If you never passed a cipher-algo option, no action is needed. To find affected rows, scan each stored value with a deliberately wrong passphrase: properly encrypted values raise an error, while affected values decrypt successfully even with the wrong key. Run the helper and the scan in the same session ( pg_temp functions are session-scoped): _ 14 create function pg_temp.affected_by_cve_2026_14663(msg bytea) _ 14 returns boolean _ 14 language plpgsql as $$ _ 14 begin _ 14 perform pgp_sym_decrypt_bytea(msg, 'deliberately-wrong-key'); _ 14 return true; _ 14 exception when others then _ 14 return false; _ 14 end $$; _ 14 _ 14 select <id_column> _ 14 from <your_table> _ 14 where <your_encrypted_column> is not null _ 14 and pg_temp.affected_by_cve_2026_14663(<your_encrypted_column>); Any rows returned hold affected values. The scan covers symmetric ( pgp_sym_* ) messages. The wrong-key probe does not apply to public-key ( pgp_pub_* ) messages. If pgp_pub_encrypt was used with an affected cipher-algo , treat those values as affected and re-encrypt them the same way using pgp_pub_decrypt and pgp_pub_encrypt with the key pair. 3. btree_gist indexes on float columns # Indexes built under the previous version can return wrong results for rows containing NaN until reindexed. Find btree_gist indexes on float columns: _ 16 select distinct _ 16 n.nspname as schema_name, _ 16 cls.relname as table_name, _ 16 ic.relname as index_name _ 16 from pg_index idx _ 16 join pg_class ic on idx.indexrelid = ic.oid _ 16 join pg_am am on ic.relam = am.oid _ 16 join pg_class cls on idx.indrelid = cls.oid _ 16 join pg_namespace n on ic.relnamespace = n.oid _ 16 join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true _ 16 join pg_opclass oc on oc.oid = k.opclass _ 16 join pg_type ty on ty.oid = oc.opcintype _ 16 where _ 16 am.amname = 'gist' _ 16 and k.pos <= idx.indnkeyatts _ 16 and ty.typname in ('float4', 'float8'); You are affected only if indexes are returned and those columns may contain NaN values. 4. Custom operators (CVE-2026-2004) # Only superusers may now attach a non-built-in selectivity estimator to an operator. Existing operators keep working. Only re-creation (dump/restore, branching, major-version upgrade) fails. Operators installed by extensions (PostGIS, intarray, etc.) are not affected. Check for affected operators: _ 13 select _ 13 n.nspname as schema, o.oprname as operator, _ 13 o.oprrest::regproc as restrict_estimator, _ 13 o.oprjoin::regproc as join_estimator _ 13 from pg_operator o _ 13 join pg_namespace n on o.oprnamespace = n.oid _ 13 where n.nspname not in ('pg_catalog', 'information_schema') _ 13 and ((o.oprrest <> 0 and o.oprrest::oid >= 10000) _ 13 or (o.oprjoin <> 0 and o.oprjoin::oid >= 10000)) _ 13 and not exists ( _ 13 select 1 from pg_depend d _ 13 where d.classid = 'pg_operator'::regclass and d.objid = o.oid and d.deptype = 'e' _ 13 ); What happens if you take no action # ltree / btree_gist: affected index searches may silently return wrong or incomplete results - no error is raised. pgcrypto: decryption of affected messages fails by default after the upgrade (recoverable with the ignore-cipher-failure=1 decrypt option). The underlying data remains effectively unencrypted at rest until re-encrypted. Custom operators: a future dump/restore, branch, or major-version upgrade fails to recreate the operator. Migration steps # Run the detection queries above for each database. After upgrading, reindex each affected ltree/btree_gist index using its schema-qualified name — REINDEX INDEX CONCURRENTLY <schema_name>.<index_name>; runs online with no downtime, but cannot run inside a transaction block. For pgcrypto: re-encrypt affected values with a modern cipher (for example cipher-algo=aes256 ), before the upgrade or after it using ignore-cipher-failure=1 , and consider rotating secrets stored this way. For custom operators: recreate without the RESTRICT / JOIN clause (or with a built-in estimator), or contact support and we'll assist. Rollout timeline # Date Milestone User action 2026-09-25 Release announce (this entry) Run detection queries 2026-09-28 New projects created on 15.19 / 17.11 — 2026-09-28 Upgrade available in dashboard for existing projects Upgrade, then reindex if affected Database 2026 2026 New Feature Logs usage-based pricing

A minor release of PostgreSQL 15.19 and 17.11 is being rolled out, which includes five upstream security cycles and fixes 44 CVEs, but may require action for ltree, pgcrypto, btree_gist, and custom operators.

2026-09-18

PostgreSQL 15.19 / 17.11 minor release — action may be required for ltree, pgcrypto, btree_gist, and custom operators Sep 25, 2026 Breaking Change [data-ch-theme="supabase"] { --ch-t-colorScheme: var(--ch-0);--ch-t-foreground: var(--ch-4);--ch-t-background: var(--ch-16);--ch-t-editor-background: var(--ch-16);--ch-t-editor-foreground: var(--ch-4);--ch-t-editor-rangeHighlightBackground: var(--ch-19);--ch-t-editor-infoForeground: var(--ch-18);--ch-t-editor-selectionBackground: var(--ch-17);--ch-t-tab-activeBackground: var(--ch-16);--ch-t-tab-activeForeground: var(--ch-4);--ch-t-tab-inactiveBackground: var(--ch-21);--ch-t-tab-inactiveForeground: var(--ch-15);--ch-t-tab-border: var(--ch-22);--ch-t-tab-activeBorder: var(--ch-16);--ch-t-editorGroupHeader-tabsBackground: var(--ch-21);--ch-t-editorLineNumber-foreground: var(--ch-20);--ch-t-input-foreground: var(--ch-4);--ch-t-sideBar-foreground: var(--ch-4);--ch-t-list-hoverBackground: var(--ch-25);--ch-t-list-hoverForeground: var(--ch-4); } What changed # We are rolling out the PostgreSQL 15.19 / 17.11 minor release (from 15.14 / 17.6). It bundles five upstream security cycles and closes 44 CVEs . Four changes may require action, depending on how you use your database: ltree indexes may need reindexing — a case-folding fix on multibyte/ICU databases, plus an integer-overflow fix for very deep ltree values (any encoding). pgcrypto stops decrypting legacy-cipher PGP data (CVE-2026-14663) — data encrypted with cipher-algo=bf / blowfish / cast5 was effectively stored unencrypted and fails to decrypt by default after the upgrade. btree_gist indexes on float columns that may contain NaN need reindexing. Custom operators with non-built-in selectivity estimators (CVE-2026-2004) — recreating them (dump/restore, branching) now requires superuser. If none of the detection queries below return rows for your project, no action is needed. Why we made this change # This is an upstream PostgreSQL minor release. Staying current closes 44 CVEs (including several rated High) and picks up correctness fixes in the ltree and btree_gist extensions. Who is affected # 1. ltree indexes # Case-folding (multibyte/ICU) # After upgrading, indexes on ltree columns built under the previous version can silently return incomplete results on databases using a multibyte encoding (such as UTF-8) or a non- libc collation provider (ICU or builtin). Check whether your database is affected: _ 10 select _ 10 pg_encoding_to_char(encoding) as encoding, _ 10 pg_encoding_max_length(encoding) as max_bytes_per_char, -- 1 = single-byte, >1 = multibyte _ 10 datlocprovider as collation_provider, -- 'c' libc, 'i' icu, 'b' builtin _ 10 (pg_encoding_max_length(encoding) > 1 or datlocprovider != 'c') as reindex_required _ 10 from pg_database _ 10 where datname = current_database(); If reindex_required is true , find the affected indexes: _ 14 select distinct _ 14 n.nspname as schema_name, _ 14 cls.relname as table_name, _ 14 ic.relname as index_name _ 14 from pg_index idx _ 14 join pg_class ic on idx.indexrelid = ic.oid _ 14 join pg_class cls on idx.indrelid = cls.oid _ 14 join pg_namespace n on ic.relnamespace = n.oid _ 14 join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true _ 14 join pg_opclass oc on oc.oid = k.opclass _ 14 join pg_type ty on ty.oid = oc.opcintype _ 14 where _ 14 k.pos <= idx.indnkeyatts -- key columns only, excludes INCLUDE _ 14 and ty.typname in ('ltree', '_ltree'); Integer overflow (any encoding) # This release also fixes an integer overflow in ltree comparisons: values with more than about 14,653 labels could compare incorrectly, which can corrupt B-tree indexes built over them, regardless of your database encoding. This query lists only the B-tree indexes that actually contain such values (an empty result means no action is needed): _ 35 select s.schema_name || '.' || s.index_name as index_to_reindex _ 35 from ( _ 35 select _ 35 n.nspname as schema_name, _ 35 c.relname as table_name, _ 35 ic.relname as index_name, _ 35 min(pg_get_expr(i.indpred, i.indrelid)) as pred, -- partial-index predicate, if any _ 35 string_agg('nlevel(' || pg_get_indexdef(i.indexrelid, k.pos::int, true) || ') > 14653', ' or ') as keys_cond _ 35 from pg_index i _ 35 join pg_class ic on ic.oid = i.indexrelid _ 35 join pg_class c on c.oid = i.indrelid _ 35 join pg_namespace n on n.oid = c.relnamespace _ 35 join pg_am am on am.oid = ic.relam _ 35 join lateral generate_series(1, i.indnkeyatts) as k(pos) on true _ 35 join pg_attribute ia on ia.attrelid = i.indexrelid and ia.attnum = k.pos _ 35 join pg_type t on t.oid = ia.atttypid _ 35 where am.amname = 'btree' _ 35 and t.typname = 'ltree' _ 35 and n.nspname not in ('pg_catalog', 'information_schema') _ 35 group by n.nspname, c.relname, ic.relname _ 35 ) s _ 35 where (xpath( _ 35 '/row/cnt/text()', _ 35 query_to_xml( _ 35 format('select count(*) as cnt from %I.%I where %s(%s)', _ 35 s.schema_name, _ 35 s.table_name, _ 35 case when s.pred is not null then '(' || s.pred || ') and ' else '' end, _ 35 s.keys_cond), _ 35 false, _ 35 true, _ 35 '' _ 35 ) _ 35 ))[1]::text::bigint > 0 _ 35 order by 1; 2. pgcrypto legacy ciphers (CVE-2026-14663) # If you call pgp_sym_encrypt / pgp_pub_encrypt (or their _bytea variants) with cipher-algo=bf , cipher-algo=blowfish , or cipher-algo=cast5 , that data was effectively stored unencrypted — decryption succeeds even with the wrong key. The default cipher (AES) and 3des are not affected. If you never passed a cipher-algo option, no action is needed. To find affected rows, scan each stored value with a deliberately wrong passphrase: properly encrypted values raise an error, while affected values decrypt successfully even with the wrong key. Run the helper and the scan in the same session ( pg_temp functions are session-scoped): _ 14 create function pg_temp.affected_by_cve_2026_14663(msg bytea) _ 14 returns boolean _ 14 language plpgsql as $$ _ 14 begin _ 14 perform pgp_sym_decrypt_bytea(msg, 'deliberately-wrong-key'); _ 14 return true; _ 14 exception when others then _ 14 return false; _ 14 end $$; _ 14 _ 14 select <id_column> _ 14 from <your_table> _ 14 where <your_encrypted_column> is not null _ 14 and pg_temp.affected_by_cve_2026_14663(<your_encrypted_column>); Any rows returned hold affected values. The scan covers symmetric ( pgp_sym_* ) messages. The wrong-key probe does not apply to public-key ( pgp_pub_* ) messages. If pgp_pub_encrypt was used with an affected cipher-algo , treat those values as affected and re-encrypt them the same way using pgp_pub_decrypt and pgp_pub_encrypt with the key pair. 3. btree_gist indexes on float columns # Indexes built under the previous version can return wrong results for rows containing NaN until reindexed. Find btree_gist indexes on float columns: _ 16 select distinct _ 16 n.nspname as schema_name, _ 16 cls.relname as table_name, _ 16 ic.relname as index_name _ 16 from pg_index idx _ 16 join pg_class ic on idx.indexrelid = ic.oid _ 16 join pg_am am on ic.relam = am.oid _ 16 join pg_class cls on idx.indrelid = cls.oid _ 16 join pg_namespace n on ic.relnamespace = n.oid _ 16 join lateral unnest(idx.indclass::oid[]) with ordinality as k(opclass, pos) on true _ 16 join pg_opclass oc on oc.oid = k.opclass _ 16 join pg_type ty on ty.oid = oc.opcintype _ 16 where _ 16 am.amname = 'gist' _ 16 and k.pos <= idx.indnkeyatts _ 16 and ty.typname in ('float4', 'float8'); You are affected only if indexes are returned and those columns may contain NaN values. 4. Custom operators (CVE-2026-2004) # Only superusers may now attach a non-built-in selectivity estimator to an operator. Existing operators keep working. Only re-creation (dump/restore, branching, major-version upgrade) fails. Operators installed by extensions (PostGIS, intarray, etc.) are not affected. Check for affected operators: _ 13 select _ 13 n.nspname as schema, o.oprname as operator, _ 13 o.oprrest::regproc as restrict_estimator, _ 13 o.oprjoin::regproc as join_estimator _ 13 from pg_operator o _ 13 join pg_namespace n on o.oprnamespace = n.oid _ 13 where n.nspname not in ('pg_catalog', 'information_schema') _ 13 and ((o.oprrest <> 0 and o.oprrest::oid >= 10000) _ 13 or (o.oprjoin <> 0 and o.oprjoin::oid >= 10000)) _ 13 and not exists ( _ 13 select 1 from pg_depend d _ 13 where d.classid = 'pg_operator'::regclass and d.objid = o.oid and d.deptype = 'e' _ 13 ); What happens if you take no action # ltree / btree_gist: affected index searches may silently return wrong or incomplete results - no error is raised. pgcrypto: decryption of affected messages fails by default after the upgrade (recoverable with the ignore-cipher-failure=1 decrypt option). The underlying data remains effectively unencrypted at rest until re-encrypted. Custom operators: a future dump/restore, branch, or major-version upgrade fails to recreate the operator. Migration steps # Run the detection queries above for each database. After upgrading, reindex each affected ltree/btree_gist index using its schema-qualified name — REINDEX INDEX CONCURRENTLY <schema_name>.<index_name>; runs online with no downtime, but cannot run inside a transaction block. For pgcrypto: re-encrypt affected values with a modern cipher (for example cipher-algo=aes256 ), before the upgrade or after it using ignore-cipher-failure=1 , and consider rotating secrets stored this way. For custom operators: recreate without the RESTRICT / JOIN clause (or with a built-in estimator), or contact support and we'll assist. Rollout timeline # Date Milestone User action 2026-09-25 Release announce (this entry) Run detection queries 2026-09-28 New projects created on 15.19 / 17.11 — 2026-09-28 Upgrade available in dashboard for existing projects Upgrade, then reindex if affected Database Logs usage-based pricing Sep 25, 2026 New Feature When you run a backend on Supabase, we instrument it for you — logs come out of the box so you can monitor your services and debug issues without standing up separate infrastructure. We're continuing to invest in them. We're also announcing usage-based pricing early, because we'd rather give impacted projects time to adjust than hand anyone an unexpected bill. More than 90% of projects are within the included limits and won't be affected; for those that are, the grace period through early 2027 gives you time to understand and tune your usage before enforcement begins. Background # We've been working for years to bring meaningful observability to Supabase developers — shipping Unified Logs , client trace integration , Log Drains , Observability Auto-Pilot , and Health Check Advisors , among other things. We'll keep going — more ways to surface logs meaningfully, more tools to help you monitor and debug, with or without an agent in the loop. But as we've scaled to millions of projects, the infrastructure behind logs has scaled with us. Usage-based pricing is how we make sure we can keep building, in a way that's fair for everyone. Usage-based pricing # That said, there are workloads where logs will scale with usage — and at platform scale, that needs to be priced fairly. We're introducing usage-based pricing for logs ingest (the volume of log data generated by your services) and a quota that scales with ingest for log query (the volume scanned when reading logs). This is a soft launch: usage is now metered and visible in your project's usage dashboard, but limits are not yet enforced. A grace period runs through early 2027, giving you time to understand your usage before billing begins. More than 90% of projects are within the included limits and won't be impacted. What we've done to control log volume # A significant part of this work has been changing default logging behavior across the Supabase stack, and giving you more control over your own: We've shipped fleet-wide changes to reduce noisy defaults — for example, disabling connection logging ( log_connections ) across most plans, which alone cut tens of millions of log rows per hour fleet-wide. Postgres log settings are configurable and often the biggest lever for teams running heavy query workloads. Settings like log_statement , log_min_duration_statement , and log_min_messages can dramatically reduce volume when tuned. See Postgres log settings and the log field reference to understand what each source captures. We've published guides to help you understand your usage and take action: Manage Logs Ingest and Manage Logs Query . We'll keep adding controls. The goal is that the defaults are right for most projects, and that teams who need to go further have the tools to do it. What's coming to Studio # Starting soon, your project's usage dashboard will show log ingest and query meters with an "Upcoming" label. If you approach your limits during the grace period, you'll see a warning in Supabase Studio — these are informational only, not enforcement actions. Why we built this # Supabase has a healthy free tier, and we're committed to keeping it that way. Usage-based pricing makes that possible: when infrastructure costs reflect actual use, high-volume projects pay their share rather than that cost being spread across the fleet. It also lets us keep finding more meaningful ways to surface logs — better tools to understand, access, and act on what they're telling you, with or without an agent in the loop — in a way that's sustainable and fair for everyone, whether you're a hobbyist, a growing startup, or a large enterprise. Share your feedback # This is a soft launch and we're actively seeking input. If you're notified about your usage during the grace period — or you have thoughts on pricing, limits, or the tooling — we'd love to hear from you. Visit our GitHub Discussion to share feedback directly with the team. Observability Database Replication is now Pipelines Sep 21, 2026 Improvement Pipelines destinations now live at Database > Pipelines in the Supabase Dashboard. This makes the page's purpose clearer now that read replicas are managed in Project Settings > Infrastructure. What changes: Open Pipelines at Database > Pipelines Existing bookmarks and pipeline detail URLs under Database > Replication redirect to the matching Pipelines page What stays the same: Pipelines destinations, configuration, and behavior Management API and database APIs Replication logs and Postgres replication terminology See the Pipelines guide for setup and monitoring instructions. Studio 2026 2026 Improvement Health Check Advisors

Supabase is rolling out a PostgreSQL 15.19 / 17.11 minor release, which bundles five upstream security cycles and closes 44 CVEs, but requires action for ltree, pgcrypto, btree_gist, and custom operators.

2026-09-13

Observability on Auto-Pilot

Supabase's Observability on Auto-Pilot release provides automated monitoring and logging for its database and serverless services.