Supabasesteve_chavezAnnouncement
PostgREST v10: EXPLAIN and Improved Relationship Detection
Summary
PostgREST v10 adds HTTP and supabase-js access to PostgreSQL execution plans for reads, writes, and RPC requests, with the feature restricted to development-oriented use through db-plan-enabled. Plans can be returned as text or JSON, analyzed to show execution time and RLS filtering, and queried in verbose form for the pg_stat_statements query identifier and related settings. The release also improves relationship detection: unique or foreign-key primary keys produce one-to-one JSON objects, while computed relationships let SQL functions define efficient links for views and materialized views. Many-to-many detection now requires a join table’s primary key to include both foreign-key columns, a breaking change; the post says PostgREST 10 was not yet on the Supabase Platform and was planned for release there over the following month.
Context
The execution-plan feature is intended to provide quicker performance feedback, especially when evaluating RLS policies. Relationship detection needed improvement because views cannot have foreign keys and inference can fail for complex definitions; complex schemas could also cause join tables to be detected incorrectly. One-to-one embedding should avoid unnecessary JSON arrays.
Approach / What changed
PostgREST exposes PostgreSQL plans through an HTTP vendor media type and the supabase-js explain() transform, with analyze, format, verbose, settings, buffers, and wal options. Relationship detection uses uniqueness or a foreign-key primary key for one-to-one links, while inlinable SQL functions define computed relationships for views and materialized views. Many-to-many join-table detection now requires a composite primary key containing both foreign-key columns.
Takeaways
explain() works across supabase-js methods, including rpc(), and can show RLS filters, execution time, and the pg_stat_statements query identifier.
Computed relationships use stable, inlinable SQL functions to connect views or materialized views and can also override detected relationships.
Many-to-many join tables must have a primary key that includes the foreign-key columns on both ends; otherwise computed relationships are the stated alternative.
Source and freshness
- Source
- supabase.com
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.