Securing Your Supabase API with Row Level Security (RLS)
Stop writing middleware for basic authorization. Learn how to use Supabase Row Level Security (RLS) to move your access control directly into Postgres for a more secure, scalable API.
Loading…
ReadMeFeed / Community knowledge
Supabase
Real questions. Useful conversations. Find the people who know your stack.
Supabase
Cloud & infrastructure · #supabase
Subscribe to Supabase Realtime: A Practical Guide to WebSocket Table Changes
Learn how to subscribe to Supabase Realtime via WebSocket, configure RLS and permissions, and avoid common pitfalls. Includes a live code example, limits, and verification steps.
Supabase CLI and GitHub Actions: Consistent Schema Migration Handling
Goal: achieve identical schema migration outcomes when running Supabase CLI locally via supabase start and in a CI pipeline that uses supabase db push against a temporary project. Constraints: the CLI does not automatically remove ephemeral Supabase projects created for CI, requiring manual cleanup to avoid quota limits, and the Docker images pulled by supab
Primary key collision during postgres_fdw migration in Supabase
When migrating data from an external PostgreSQL instance to a Supabase project using the postgres_fdw extension, the transfer of table rows does not automatically synchronize the state of sequence generators. In a zero-downtime migration strategy, data is pulled into the target Supabase instance while the source continues to accept writes. If the target sequ
Supabase client retry behavior and PostgreSQL upsert interaction for idempotent writes
Goal: Ensure that a write operation retried by the Supabase client does not result in duplicate rows in the underlying PostgreSQL table. The Supabase JavaScript SDK automatically retries failed network requests with exponential back‑off, but it does not deduplicate the corresponding INSERT or UPDATE statements. Developers must therefore rely on database‑leve
Backup not found error when restoring expired Supabase database snapshot
Restoring a database snapshot beyond the plan retention window The goal is to recover a Supabase project database from a daily backup that falls outside the current plan's retention period. On the free tier, automated backups are retained for seven days; paid plans extend this to thirty days. Point-in-time recovery is only available on Pro and higher plans.
PostgREST pagination latency during high offset requests
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
Supabase Realtime: WAL accumulation during high-churn table replication
PostgreSQL Logical Replication and Storage Supabase Realtime leverages the supabase_realtime publication and logical replication slots to stream database changes to clients via WebSockets. This architecture relies on the PostgreSQL Write Ahead Log (WAL) to track and broadcast INSERT , UPDATE , and DELETE events. Resource Constraints In environments with high
Which alerting signals should a Supabase project route to an external sink before dashboard notifications become noise?
Our team runs a production Supabase project and wants alerting that is genuinely actionable. The platform exposes several distinct signal sources: query performance data built on pg_stat_statements, Auth audit events, connection pool saturation, and usage metrics for compute, bandwidth, and database size. Dashboard notifications cover some of this, while log