.eq() filter returns empty results on Vercel Serverless Functions

[the-fixr]

Bug Report

Describe the bug

Single-column .eq() filters on certain tables silently return empty arrays when running inside Vercel Serverless Functions. The exact same query works correctly via the Supabase REST API (curl) and in local development (next dev).

To Reproduce

Table schema:

CREATE TABLE check_ins (
  id BIGSERIAL PRIMARY KEY,
  epoch_day INTEGER NOT NULL,
  wallet TEXT NOT NULL,
  weight INTEGER NOT NULL DEFAULT 1,
  checked_in_at TIMESTAMPTZ DEFAULT NOW(),
  UNIQUE(epoch_day, wallet)
);
CREATE INDEX idx_checkins_wallet ON check_ins(wallet);
ALTER TABLE check_ins ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Public read check_ins" ON check_ins FOR SELECT USING (true);

Code that fails on Vercel (returns empty data):

const { data, error } = await supabase
  .from('check_ins')
  .select('epoch_day, weight, wallet')
  .eq('wallet', walletAddress);
// data = [] on Vercel, correct results locally and via REST API

Same query via REST API works:

curl "https://<project>.supabase.co/rest/v1/check_ins?wallet=eq.<wallet>&select=epoch_day,weight,wallet" \
  -H "apikey: <service_key>" -H "Authorization: Bearer <service_key>"
# Returns correct rows

Workaround that works everywhere:

const { data: all } = await supabase
  .from('check_ins')
  .select('epoch_day, weight, wallet')
  .limit(10000);
const rows = (all || []).filter((r) => r.wallet === walletAddress);

Additional observations

1. .eq() with a second filter works fine: .eq('epoch_day', X).eq('wallet', wallet) returns correct results. The issue only appears when .eq('wallet', wallet) is the sole filter.

2. .in().gt() chained filters also fail: .in('epoch_day', [...]).gt('total_weight', 0) returns empty despite matching rows existing. Splitting into .in() only and filtering .gt() in JS resolves it.

3. .select('*', { count: 'exact', head: true }) with .eq() also returns 0 despite rows existing.

4. .select().limit(N) without any .eq() filter returns correct results, confirming the data is accessible.

5. The same client instance (service role key, same createClient call) works for .eq() on other tables.

6. Issue reproduces with both anon key and service_role key.

7. RLS is enabled with a permissive FOR SELECT USING (true) policy.

Expected behavior

.eq('wallet', walletAddress) should return the same rows as the equivalent REST API query.

Environment

• @supabase/supabase-js: ^2.49.1
• Runtime: Vercel Serverless Functions (Node.js 22.x)
• Framework: Next.js 14 (App Router, force-dynamic)
• Supabase: Hosted (free tier)
• Region: US East

Possible causes

• PostgREST query planner behaving differently with single-filter vs multi-filter queries
• Connection pooling or stale schema cache in serverless cold starts
• RLS policy evaluation interacting with the query in unexpected ways
• supabase-js query builder serializing the filter differently than expected

[mandarini]

Thanks for the detailed write-up. After looking into this, this is almost certainly not a bug in supabase-js.

The entire .eq() implementation is:

this.url.searchParams.append(column, `eq.${value}`)

That's it, one line. There is no conditional logic that behaves differently based on how many filters are chained. For your query:

supabase.from('check_ins').select('epoch_day, weight, wallet').eq('wallet', walletAddress)

supabase-js generates this URL:

GET /rest/v1/check_ins?select=epoch_day%2Cweight%2Cwall et&wallet=eq.<walletAddress>

Which is byte-for-byte equivalent to your working curl command. The library cannot be responsible for returning different results.

I think the most likely cause is Next.js fetch cache. Next.js App Router patches the global fetch and caches responses by URL by default. export const dynamic = 'force-dynamic' prevents the route's rendered output from being cached, but it does not guarantee cache: 'no-store' on individual fetch() calls made inside that route, this is a well-known source of confusion.

Here's what likely happened: on a cold start (or during build), the specific URL ?wallet=eq.<address> was fetched and the response (possibly empty at that moment, or from a different request context) got stored in Next.js's fetch cache. Subsequent calls with the exact same URL hit the cache. Your double-filter query ?epoch_day=eq.X&wallet=eq.<address> has a different URL, so it's a cache miss and hits the real database.

This also explains why .limit(10000) works, it's a different URL with no warm cache entry.

You can try to pass { cache: 'no-store' } via the global.fetch override when creating your Supabase client:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, {
  global: {
    fetch: (url, options = {}) => fetch(url, { ...options, cache: 'no-store' }),
  },
})

Or add this to your route/layout file to opt the entire route out of fetch caching:

export const fetchCache = 'force-no-store'

Before anything else, please verify the URL supabase-js is actually sending. Add this temporarily:

const supabase = createClient(url, key, {
  global: {
    fetch: (input, init) => {
      console.log('[supabase fetch]', input.toString())
      return fetch(input, init)
    },
  },
})

Check the Vercel function logs and confirm:

1. The wallet value in the URL is what you expect (correct casing, no whitespace, not undefined)
2. The URL is being requested at all on every invocation (not short-circuited before fetch)

The other candidate is a PostgREST / RLS query planner difference. Single-column filters on indexed columns can trigger a different query plan in PostgreSQL, and there are known edge cases where RLS policies interact unexpectedly with index scans. If the cache: 'no-store' fix doesn't help, this would be worth filing against supabase/supabase with a minimal Supabase project reproduction — not supabase-js.

Without a reproduction that isolates the issue to the JS library itself (i.e., the same empty result happening with a plain fetch() call to the same URL), I can't action this as a supabase-js bug. If the cache: 'no-store' workaround fixes it, the issue is entirely on the Next.js side.

Thank you for taking the time to report this, and please let me know of your findings!