stillshipOne feed. Every update.
See what shipped.
Follow the apps you care about. Stillship turns scattered changelogs into one calm, searchable feed.
447 apps trackedLatest ships
Updated dailySupabasePostgreSQL 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 ↗2026-09-18