Anonymous (logged-out) PostgREST queries return stale public data while authenticated queries are current

[staystrangeapp]

Hi Supabase team,

I'm seeing what appears to be a project-specific issue affecting anonymous (logged-out) reads.

Project

Project Reference: yvqicujzfkeyymwdvnbf

Expected behavior

A newly created Community/Public record should become visible immediately to both authenticated and anonymous users.

Actual behavior

Authenticated users immediately see newly created public records.

Anonymous (logged-out) users continue seeing an older snapshot of the public data even after repeated refreshes and waiting several minutes.

Reproduction
Sign in.
Create a new Community/Public observation.
Confirm it appears immediately while authenticated.
Open a completely logged-out/private browser session.
Visit the public feed.
The new public record does not appear.
What we've already verified
The insert succeeds.
The record appears on the author's profile.
The record appears in the authenticated Recent Observations feed.
RLS policies have been reviewed and appear correct.
Authenticated users consistently receive fresh data.
The issue only affects anonymous requests.
The issue reproduces across multiple browsers and private/incognito sessions.
The behavior persisted after deploying a new production build.

Question

Has anyone seen anonymous PostgREST reads become "stuck" or serve stale data for a single project while authenticated reads remain current?

Is there anything we should inspect regarding the anonymous connection pool, PostgREST session, or project configuration?

If additional diagnostics or request IDs would help, I'm happy to provide them.

Thank you!

[GaryAustin1]

Supabase does not cache. But something like next.js can and does depending on your settings. Check in the API Gateway log and see if the request even makes it to the Supabase server.

If a request was blocked by RLS you would get no data back and not stale data.

[TizianoGreco]

Building on Gary's point — the split you're describing (authenticated always fresh, anonymous stale, across browsers, surviving a redeploy) is the classic signature of an HTTP/framework cache layer in front of Supabase, not of PostgREST itself. Authenticated requests carry an Authorization header (and usually cookies), which makes every cache layer treat them as uncacheable/dynamic; anonymous GETs are exactly the requests that CDNs and frameworks happily cache or prerender.

A quick way to prove where the staleness lives — query PostgREST directly, bypassing your app entirely:

curl 'https://<project-ref>.supabase.co/rest/v1/<table>?select=*&order=created_at.desc&limit=5' \
  -H "apikey: <anon-key>" \
  -H "Authorization: Bearer <anon-key>"

If that returns the new record (it almost certainly will), Supabase's anonymous path is fine and the snapshot is being served by your frontend stack.

Then, assuming a Next.js/Vercel-style setup (adjust for your framework):

• Static/ISR prerendering: a public feed page with no cookies/headers/dynamic APIs gets prerendered and served as static HTML — that's an "older snapshot" by definition. The authenticated version of the page reads the auth cookie, which forces dynamic rendering, hence always fresh. Fix with export const dynamic = 'force-dynamic' (or a suitable revalidate) on the public route.
• Persistent data cache: this is the detail that matches your "persisted after deploying a new production build" observation — on Vercel, the Data Cache (cached fetch results) survives deployments. A redeploy does not flush it; you need revalidatePath/revalidateTag, a cache purge from the dashboard, or explicit cache: 'no-store' on the fetches.
• Diagnosis via headers: open the public feed logged-out and inspect the document/API responses for x-vercel-cache: HIT, age:, or cf-cache-status: headers — they tell you exactly which layer answered without hitting Supabase.

Gary's suggestion is the corresponding server-side check: if the anonymous page load doesn't even show up in the API Gateway logs, no request reached Supabase at all, which confirms the cached-frontend theory.

[luantaraschi]

Before digging into the anonymous connection pool or PostgREST session state, it's worth isolating whether PostgREST is actually the thing serving stale data. In reports shaped like this one it usually isn't.

The reason is that "logged out" and "logged in" almost always differ by more than the database role. On the client, an anonymous request carries no per-user Authorization bearer, which is exactly what makes it cacheable by a CDN or by your framework's data cache. Authenticated requests vary per user, so they bypass those layers and always look current. That asymmetry produces precisely your symptom — fresh for authenticated, an older snapshot for anonymous — without anything being wrong in Postgres.

Two checks that separate the layers

1. Hit PostgREST directly, bypassing your app entirely.

curl -s \
  -H "apikey: <ANON_KEY>" \
  -H "Authorization: Bearer <ANON_KEY>" \
  "https://<project-ref>.supabase.co/rest/v1/<table>?select=id,created_at&order=created_at.desc&limit=5"

Run it immediately after creating a record that isn't showing up. This uses the anon role, same as a logged-out browser, but with none of your application code in the path.

• New row present → the anonymous path through Postgres and PostgREST is current. The staleness is downstream: your framework's data/route cache, a CDN in front of your app, or a service worker. Nothing for Supabase to fix.
• New row missing → now you have a genuine project-level report, and a much stronger one.

2. Look at the response headers on the request your app makes when logged out.

Check age, cache-control, x-cache, and cf-cache-status. A non-zero age on the logged-out response with no equivalent on the authenticated one confirms an intermediary cache is answering, and tells you which layer to configure.

One RLS detail to rule out while you're there

anon and authenticated are distinct Postgres roles. A policy written to authenticated, or one whose using clause depends on auth.uid(), never applies to logged-out reads at all. Worth confirming your public-read policy is to anon, authenticated (or to public) rather than to authenticated.

That said, I'd expect an RLS gap to produce "anonymous users never see these rows" rather than "anonymous users see an older snapshot". If older public records do appear anonymously and only the newest ones are missing, caching fits the evidence better than RLS does. If instead the anonymous view is missing rows regardless of age, look at the policy first.

If check 1 does reproduce

That's the case worth escalating, and it'd be genuinely unusual. Include in the report:

• the exact curl above with its timestamp and full response
• a matching authenticated curl run seconds apart showing the row present
• the request id from the response headers of the anonymous call

Two curl calls seconds apart, one showing the row and one not, is a far more actionable artifact than a browser-level description — it removes every client-side variable from the discussion in one shot.

[cekuu35]

The cache explanations above are the most likely answer and the curl test is the right first move. But there is a second family of cause that fits your description just as well, and it is worth ruling out in the same sitting because the fix is completely different.

Gary's point that "if a request was blocked by RLS you would get no data back and not stale data" holds for a policy that denies everything. It does not hold for a policy that denies some rows — and there the symptom is indistinguishable from a stale cache: an anonymous reader sees a set of rows that stops at some point in the past and never advances.

Your own wording is what makes me raise it. You write "Create a new Community/Public observation", which suggests a record can be one of at least two visibility states. If the anonymous policy admits only one of them and new records are being written as the other, then:

• the author sees it (own-row policy),
• the authenticated feed sees it (that policy admits both states),
• anonymous never sees it,
• and because older rows were written in the admitted state, anonymous appears frozen at an older snapshot.

Every line of your report is satisfied by that, including surviving a redeploy and reproducing across browsers and incognito — which is exactly the evidence being read as "it must be a cache".

The discriminator, with no HTTP layer involved at all:

begin;
select set_config('request.jwt.claims', '{"role":"anon"}', true);
set local role anon;

select count(*)          as rows_anon_sees,
       max(created_at)   as newest_row_anon_sees
from public.observations;      -- your table name here

rollback;

Then compare against the unrestricted view:

select count(*) as rows_total, max(created_at) as newest_row_total
from public.observations;

• If newest_row_anon_sees is stuck in the past, nothing outside the database is involved. It is the policy, and the cache hunt is the wrong tree.
• If anon sees the new row here, then PostgREST would serve it too, and the staleness lives above the database — at which point the curl test tells you whether it is the CDN or your framework.

Note the set_config line specifically: set role anon on its own leaves request.jwt.claims unset, so auth.uid() and auth.role() evaluate against NULL rather than against an anonymous request. That is the usual reason a hand-run RLS check disagrees with what the API actually does, in both directions.

If it does turn out to be the policy, this is the query that shows you why in one pass:

select p.polname,
       case p.polcmd when 'r' then 'SELECT' when '*' then 'ALL' else p.polcmd::text end as cmd,
       array(select rolname from pg_roles where oid = any(p.polroles)) as roles,
       pg_get_expr(p.polqual, p.polrelid) as using_expr
from pg_policy p
join pg_class c     on c.oid = p.polrelid
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relname = 'observations'
order by p.polcmd, p.polname;

An empty roles array means the policy has no TO clause and is therefore evaluated for every role including anon — worth knowing which of your policies anonymous readers are actually landing on before you change anything.