Native rate limiting for client-side SELECT requests to prevent egress abuse

[ericzager0]

I have a Next.js SaaS on Vercel that communicates directly from the browser with Supabase, secured with RLS. My concern is that a malicious authenticated user could script millions of SELECT calls from the browser console and generate huge egress costs. Is there any native Supabase mechanism to prevent this without routing requests through a server-side proxy?

[C1616]

Hi @ericzager0 1. You can write a SQL function that runs before every Supabase Data API request. Inside it you can check how many requests the current user (from their JWT) has made in the last minute, and raise an error if they exceed a limit. You log each request in a table.
2. Supabase Edge Function or Vercel Edge Middleware that rate‑limits requests before forwarding to Supabase

[ericzager0]

I like the first approach. How can I achieve it?

[C1616]

1. Create a log table

create table request_logs (
  id bigint generated always as identity primary key,
  user_id uuid,
  created_at timestamptz default now()
);

create index on request_logs (user_id, created_at);

2. The guard function does two things in one shot it checks the count, raises an error if the user is over limit

create or replace function check_rate_limit(max_requests int default 100)
returns void language plpgsql security definer as $$
declare
request_count int;
lock_row request_logs%rowtype;
begin
select * into lock_row
from request_logs
where user_id = auth.uid()
order by created_at desc
limit 1
for update;

select count(*) into request_count
from request_logs
where user_id = auth.uid()
and created_at > now() - interval '1 minute';

if request_count >= max_requests then
raise exception 'Rate limit exceeded';
end if;

insert into request_logs (user_id) values (auth.uid());
end;
$$;

3. The guard function uses SELECT ... FOR UPDATE before counting. This is the critical detail. Without it, two requests arriving at the same millisecond both read the same count, both see they're under the limit, and both go through

create or replace function check_rate_limit(max_requests int default 100)
returns void language plpgsql security definer as $$
declare
request_count int;
lock_row request_logs%rowtype;
begin
select * into lock_row
from request_logs
where user_id = auth.uid()
order by created_at desc
limit 1
for update;

select count(*) into request_count
from request_logs
where user_id = auth.uid()
and created_at > now() - interval '1 minute';

if request_count >= max_requests then
raise exception 'Rate limit exceeded';
end if;

insert into request_logs (user_id) values (auth.uid());
end;
$$;

4. Wrap your actual queries in an RPC function that calls the guard first. The real query only executes if the guard passes silently:

create or replace function get_my_data()
returns setof your_table language plpgsql security definer as $$
begin
  perform check_rate_limit(100);
  return query
    select * from your_table where user_id = auth.uid();
end;
$$;

5. On the client you just call the RPC normally and handle the error if it fires

const { data, error } = await supabase.rpc('get_my_data');
if (error?.message === 'Rate limit exceeded') {
  // show the user a friendly message or back off and retry
}

[ericzager0]

I really like the idea. it seems to work. It’s not the cleanest solution, but it gets the job done. however, I do have a concern: doesn’t it introduce a lot of overhead?

Is there any official or recommended solution from Supabase for this problem? I’ve been looking around in forums and theres not much discussion about it, which worries me. Supabase seems to recommend using the Data API directly from the client by default, but it doesn’t provide built-in rate limiting. A malicious user could just run a loop from the console and quickly burn through egress, potentially taking the project down.

Does this mean Supabase is more suited for toy projects and not really intended for production, or am I missing something?

[C1616]

I haven't come across any official Supabase documentation addressing per-user rate limiting. That said, Supabase works well for production workloads overall.
As suggested earlier, one alternative is to implement rate limiting in an Edge Function using Upstash Redis as the backing store. Upstash works natively in Deno via HTTP, so no persistent connection is needed, making it a natural fit for Supabase Edge Functions.

[ericzager0]

I think the edge functions and Redis option you mentioned is the cleanest conceptually. but it raises a question for me. If I want all communication with supabase to go through those edge functions, should I remove the policies from all the tables to prevent the client from communicating directly through that path?

[C1616]

Do not remove RLS policies keep them as your last line of defense.

Instead, in Supabase Dashboard → Settings → API, restrict the Data API to only accept the service role key. This blocks direct browser access via the anon key while your Edge Functions still work since they use the service role key server-side.

Think of it in layers:

1. Edge Function plus Upstash - rate limiting, only public entry point
2. Service role key - used inside the Edge Function only, never exposed to the browser
3. RLS - backstop in case anything slips through

Removing RLS would leave your data completely exposed if the service role key was ever compromised.