Supabase Removes logs.all on 2026-09-23: Port Your Queries First

On 2026-09-23, Supabase removes the logs.all endpoint from its Management API. The changelog entry, announced 2026-07-23, is one sentence: "The Supabase Management API logs.all endpoint is removed on 2026-09-23. Scripts calling it must migrate to the new ClickHouse-backed logs endpoint, which accepts ClickHouse SQL only."

Read that second sentence twice, because it is the part teams miss. This is not a URL swap. The old endpoint accepted BigQuery-style SQL against per-source log tables. The new one accepts ClickHouse SQL against a single unified table with a different schema for nested fields. Every saved query, alerting script, and compliance export that calls logs.all has to be rewritten in a different SQL dialect, and the endpoint it depends on stops answering in 25 days.

If your product runs on Supabase and you have ever wired log queries into an alert, a dashboard, an incident runbook, or a scheduled export, this deadline is yours. Here is what breaks, why the obvious fix does not work, and the exact rewrites to ship before the date.

The Real Business Bottleneck#

The dangerous thing about this removal is not the outage it causes. It is the outage it hides.

When a customer-facing API dies, you find out immediately: requests fail, users complain, the incident channel lights up. When a logging API dies, the opposite happens. Your alerting script calls a dead endpoint, gets an error, and depending on how it was written, either crashes silently or reports "no results found." No results looks exactly like no errors. A team can run blind for weeks before anyone notices that the reason production looks quiet is that nobody is listening.

That is the reliability exposure: on 2026-09-23, every script still pointed at logs.all stops observing production, and most of them will fail in the direction that looks like good news.

The cost exposure is the rewrite itself. Per Supabase's migration discussion, the change is threefold. The endpoint path moves from analytics/endpoints/logs.all to analytics/endpoints/logs. The per-source tables (edge_logs, postgres_logs, function_logs, and the rest) collapse into one logs table filtered by a source column. And the query language changes: nested metadata that the old dialect reached through chained cross join unnest() calls is now a flat log_attributes map read with bracket notation. Three changes per query, multiplied by every query you own. A team with a dozen alerting rules and two compliance exports is looking at real scheduled work, not a config change.

There is also a scope exposure that is easy to miss: you may be affected without having written a single log query yourself. Supabase notes that the get_logs tool in its MCP server called logs.all internally, so AI agents wired to Supabase through MCP were hitting the doomed endpoint too. Updating to mcp-server-supabase v0.10.0 fixes that path with no further changes. Dashboard users are safe: the Logs Explorer UI is not affected. The blast radius is precisely "anything that calls the Management API logs endpoint directly."

We covered what a vendor sunset looks like when the replacement column is empty in our Sora Videos API exit plan. This one is the friendlier case, a named successor exists, but the successor speaks a different language, which puts it closer to a re-platforming than a rename.

Why the Naive Fix Fails#

The reflex fix is a one-line diff: change logs.all to logs in the endpoint path and move on. It will fail on the first request, for three verifiable reasons.

Your table names no longer exist. The old dialect queried edge_logs or postgres_logs as tables. The new endpoint exposes one table, logs, and expects the source as a WHERE filter. A query with from edge_logs in it has nothing to bind to.

Your unnest chains no longer parse. BigQuery-style cross join unnest(metadata) is how the old queries reached nested fields like a request path or a status code. ClickHouse does not accept that construction against this schema. The replacement is a flat map: log_attributes['response.status_code'], with the full dotted key inside the brackets. Every value comes back as a string, so numeric comparisons need an explicit conversion such as toInt32OrZero(), which returns 0 instead of erroring when a value is missing or malformed.

The documentation and the implementation currently disagree. The migration discussion documents the filter column as source_name, while a user in the same thread reports the deployed endpoint requires source. Supabase's own logs guide uses source in its examples. Users also report that DESCRIBE logs returns a backend error, so you cannot ask the endpoint to describe its own schema. In practice that means field names must be discovered empirically, per project, with a query we include below. Do not trust any field name, including the ones in this article, until the discovery query has confirmed it against your project.

A second reflex, "we'll do it after launch," fails on arithmetic. The window is 25 days from this writing. A parallel-run period, where old and new queries run side by side so you can compare results before the cutover, needs at least a week of overlap to catch discrepancies in real traffic. Start counting backwards from 2026-09-23 and the comfortable start date is now.

The Migration Blueprint#

The work splits into three stages: find every call site, rewrite each query, and verify against your live project before the deadline does it for you.

Stage 1: Inventory#

Every affected call site contains one of two literal strings. This scan is safe to run on any codebase and takes seconds:

grep -rn "logs.all" --include="*.ts" --include="*.js" --include="*.py" \
  --include="*.sh" --include="*.yml" --include="*.yaml" .
grep -rn "analytics/endpoints" .

Also check the places grep does not reach: scheduled jobs in your CI system, serverless crons, Grafana or Metabase data sources with inline queries, and any AI agent configured with the Supabase MCP server (fix: upgrade to mcp-server-supabase v0.10.0). Zero hits everywhere means you are done; close the ticket and diarize nothing.

Stage 2: Rewrite#

These rewrites are derived from Supabase's migration discussion, its logs documentation, and ClickHouse's function reference. We have not executed them against a live Supabase project, so actual endpoint responses are [DATA NOT AVAILABLE] here; run the discovery query in Stage 3 against your own project before wiring any of these into alerting.

Rewrite 1: tail a log source. The simplest and most common query, straight from Supabase's migration notes.

-- Before (per-source table)
select timestamp, event_message
from edge_logs
order by timestamp desc
limit 100;

-- After (unified table, ClickHouse SQL)
select timestamp, event_message
from logs
where source = 'edge_logs'
order by timestamp desc
limit 100;

Rewrite 2: find failing API requests. This is where the dialect change bites, because the old version reached the status code through nested unnests and the new one reads a map key and casts it.

-- Before (BigQuery-style nested unnest)
select cast(timestamp as datetime) as ts,
       request.path, response.status_code
from edge_logs
cross join unnest(metadata) as m
cross join unnest(m.request) as request
cross join unnest(m.response) as response
where response.status_code >= 500
order by timestamp desc
limit 100;

-- After (flat map access with explicit cast)
select timestamp,
       log_attributes['request.path'] as path,
       toInt32OrZero(log_attributes['response.status_code']) as status
from logs
where source = 'edge_logs'
  and toInt32OrZero(log_attributes['response.status_code']) >= 500
  and timestamp > now() - INTERVAL 1 HOUR
order by timestamp desc
limit 100;

Rewrite 3: hourly error trend for alerting. Time-bucketed aggregates power most alert thresholds. ClickHouse buckets timestamps with the toStartOfHour() family, and count() replaces count(*).

select toStartOfHour(timestamp) as hour,
       count() as errors
from logs
where source = 'edge_logs'
  and toInt32OrZero(log_attributes['response.status_code']) >= 500
  and timestamp > now() - INTERVAL 1 DAY
group by hour
order by hour;

Two habits from Supabase's own guidance will save you timeouts: always include a timestamp filter (long retention windows without one are the main cause of slow or failed queries), and query one source per request rather than mixing sources. Results cap at 1,000 rows per execution, so exports need pagination by time range.

Stage 3: Verify, then cut over#

Because the endpoint currently cannot describe its own schema, the field-discovery query below is the single most useful tool in the migration. It lists every attribute key your project actually emits for a source, with frequencies, so you rewrite against reality instead of documentation:

select arrayJoin(mapKeys(log_attributes)) as key, count() as n
from logs
where source = 'postgres_logs'
  and timestamp > now() - INTERVAL 1 DAY
group by key
order by n desc
limit 100;

Run it once per source you query. Then run old and new versions of each production query side by side for at least a week, comparing counts. When they agree, point the script at analytics/endpoints/logs, delete the old call, and set a calendar reminder for 2026-09-24 to confirm nothing regressed after the removal.

Two smaller Supabase changes from the same changelog window are worth folding into the same maintenance ticket. Since 2026-08-05, an explicit version in CREATE EXTENSION or ALTER EXTENSION is ignored and the default version installs with a warning, so version-pinned migration files are now silently unpinned. And self-hosted Supabase switched its default API gateway from Kong to Envoy the week of 2026-08-09; if you rely on Kong's HTTPS listener or a custom kong.yml, you must opt back in explicitly.

Can This Survive Your Workflow?#

Before scheduling the work, answer four questions:

• Do you have any hits from the Stage 1 scan? No hits and no MCP usage means this deadline does not apply to you. Verify once, then move on.
• Does anything alert off these queries? If yes, this is a reliability task with a hard date, not backlog hygiene. Broken alerting fails silently, so it goes ahead of feature work.
• Do any compliance or customer-facing exports read logs through the Management API? Those need the parallel-run week, because a discrepancy discovered after 2026-09-23 cannot be re-checked against the old endpoint.
• Does anyone on the team read ClickHouse SQL? The dialect is close enough to standard SQL that the rewrites above are followable, but the map-access and casting idioms are new. Budget a half day of learning for whoever owns the queries, not zero.

What This Costs, and What Ignoring It Costs#

For a founder deciding where this sits in the sprint, the arithmetic is short. A typical Supabase project with, say, ten log queries across alerting and one export is looking at roughly a day of engineering: an hour for the inventory scan, two to three hours of rewrites at 15 to 20 minutes per query, and the rest in the parallel-run comparison and cutover. That estimate is ours, not Supabase's; scale it to your query count.

The cost of skipping it is asymmetric. The queries do not degrade, they disappear, and they disappear in the shape of "everything looks fine." The realistic failure story is an incident in October that your alerting would have caught in September, discovered late because the script watching for it had been calling a dead endpoint and logging nothing. Incidents found by customers instead of monitors cost trust, refunds, and on-call weekends. A day of scheduled work against that risk is one of the cheaper insurance purchases available this quarter.

There is also an upside case. Teams that treat this as pure toil miss that the ClickHouse endpoint's unified table makes cross-source queries and time-bucketed analytics genuinely easier to write than the old unnest chains. If you have been meaning to build real log-based dashboards, the migration is a reasonable moment; if you want full tracing for LLM features specifically, that is a different tool class, which we covered in our self-hosted Langfuse guide.

When to Use This Guide, When to Skip It#

Use it if: the Stage 1 scan returns hits; you run the Supabase MCP server below v0.10.0; you own log-based alerting, exports, or dashboards that call the Management API; or you self-host and touched the gateway config.

Skip it if: your team only reads logs through the Supabase dashboard (the Logs Explorer is unaffected); you have no scripts calling analytics/endpoints/logs.all; or you are not on Supabase at all. Nothing here applies to the database itself, only to programmatic log access.

What Effloow Added#

The primary sources are Supabase's one-sentence changelog entry and a migration discussion thread. What we added: the silent-failure framing that makes this a reliability deadline rather than an API chore, the three-stage migration order with a parallel-run week sized against the 25 remaining days, before/after rewrites for the three query shapes that cover most production usage (tail, error filter, time-bucketed alert), every ClickHouse function verified against ClickHouse's own reference before use, the source vs source_name discrepancy and the broken DESCRIBE surfaced as things to design around, and the field-discovery query promoted to the center of the workflow because the endpoint cannot currently describe its own schema. We are explicit about the boundary: the rewrites are source-derived, and live-response verification belongs to your project, with the exact query to do it.

For Your Engineers#

Precise references for the person doing the work. Endpoint: GET/POST {management-api}/v1/projects/{ref}/analytics/endpoints/logs replaces .../analytics/endpoints/logs.all; removal date 2026-09-23, announced 2026-07-23 in changelog #48235 with details in the GitHub discussion. Dialect: ClickHouse SQL only. Schema: single logs table; filter with source = '<source>' (documented as source_name, reported working as source; test both, trust the test); known sources per the logs guide include auth_logs, edge_logs, function_edge_logs, function_logs, postgres_logs, realtime_logs, storage_logs. Nested fields: log_attributes['full.dotted.key'], string-typed, cast with toInt32OrZero(); discover keys with arrayJoin(mapKeys(log_attributes)). Aggregates: count() not count(*); bucket with toStartOfHour() / toStartOfMinute(); window with timestamp > now() - INTERVAL 1 HOUR. Limits: 1,000 rows per execution; always filter by timestamp; one source per query. MCP: upgrade mcp-server-supabase to v0.10.0. Adjacent changes: extension version pins ignored since 2026-08-05; self-hosted default gateway is Envoy as of the week of 2026-08-09, Kong is opt-in.

If your team is staring at a vendor deadline like this one, whether it is Supabase, OpenAI's retirement calendar, or an SDK major version, Effloow does exactly this work: turning a vendor's one-line changelog into an executed, verified migration with evidence you can show your customers. See what we build or tell us about your deadline. For claim-bound proof engagements, start at Proof Studio.