Supabase already gives you API Gateway and Edge Function logs, and Log Drains to forward them wherever you already watch your telemetry. What was missing → a way to tie a request in your client trace to the matching entry in those logs. You'd end up guessing which log line belonged to which slow request, based on timestamps alone.

That's fixed now. supabase-js, Swift, Flutter, and Python can all propagate W3C Trace Context to Supabase, so the request's trace_id shows up on the Supabase side too. It's opt-in, nothing changes until you turn it on. In supabase-js that's two lines: import '@supabase/supabase-js/tracing' at your entry point, then tracePropagation: true in createClient. Python goes through opentelemetry-instrumentation-httpx instead of a client flag, since that's already the Python ecosystem's way of instrumenting httpx.

Whatever tracer you already run, this should just work. OpenTelemetry, Sentry, Datadog, Honeycomb, Grafana are all W3C-compliant, though Sentry's setup differs a little from strict OTel so it's worth checking their docs. And if your sampler drops most traces, tracePropagation: { enabled: true, respectSamplingDecision: false } carries Supabase requests through regardless.

None of this costs anything extra either, it's just more value out of Log Drains you're probably already paying for.

Happy to answer questions. Full writeup: https://supabase.com/blog/connect-client-traces-to-your-logs

Postgres Changes subscriptions can now compose filters with AND across multiple columns, match on a wider set of operators, and return only the columns you ask for. All three are live now.

Quick context if you're new to it: Postgres Changes lets you subscribe to row-level inserts, updates, and deletes over a WebSocket. Filtering used to be limited to one column at a time, and every event carried the full row.

How it works:

• Separate filters with a comma: filter: 'status=eq.done,priority=eq.high'
• New operators: like, ilike, is, match, imatch, isdistinct, plus not. to negate any of them
• postgresChangesFilter() from u/supabase/supabase-js builds the same conditions in code
• Add select: ['id', 'title'] and only those columns come back. Opt in, and it needs u/supabase/supabase-js 2.109.0 or newer

Happy to answer questions!

Full writeup is here: https://supabase.com/blog/postgres-changes-filters-and-column-selection

Quick context: agents are now a primary way people build with Supabase, through our MCP server, CLI, agent skills, and docs. We wanted a repeatable way to measure how well they actually do it, rather than going on intuition.

As of today, it's open source.

How it works:

• We run coding agents including Claude Code, Codex, and OpenCode against real Supabase tasks, such as building a schema, debugging a failed Edge Function, or fixing a broken RLS policy
• Each scenario runs against a real Supabase environment, so agents call the actual MCP server and CLI, not a stub
• We score with a mix of deterministic checks and LLM-as-a-judge
• Results are published to a web app where you can group by agent, product, stage, or eval
• The harness and scenarios are on GitHub

Happy to answer any questions!

Full writeup here: https://supabase.com/blog/introducing-supabase-evals