Implementing Row Level Security in Supabase: decision guide and validation
Choose database‑enforced RLS over Edge Function gating for tenant isolation in Supabase, with policy SQL, trade‑offs and validation steps.
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Choose database‑enforced RLS over Edge Function gating for tenant isolation in Supabase, with policy SQL, trade‑offs and validation steps.
Supabase leverages PostgREST to translate API requests into SQL queries. When retrieving large datasets using the limit and offset parameters, the underlying PostgreSQL engine must scan and discard rows prior to returning the requested page. As the offset value increases, there is a potential for linear degradation in query performance, leading to increased
Goal is to make retried HTTP inserts from supabase-js safe against duplicate writes when PostgREST is used as the data API over PostgreSQL. The integration boundary has no transport-level idempotency. Idempotency is expected to be modeled in the database via a client-supplied key with a unique constraint and an upsert that maps to INSERT ... ON CONFLICT. The
Goal After migrating to supabase-js v2, I want to use the documented .abortSignal(signal) option on query builders (with AbortSignal.timeout(ms) ) to bound long-running PostgREST and RPC calls. The client-side behavior is clear: the pending promise rejects with a fetch-level AbortError. What I cannot determine is what happens on the server side once the HTTP
I am designing pagination for a large table in Supabase (queried through supabase-js, so PostgREST semantics underneath). The dataset is big enough that pages will be fetched sequentially by users while other clients keep inserting and occasionally deleting rows. The simple option is the range(from, to) helper (limit/offset style). My concern is that page bo