Contents
On September 23, Supabase removed the logs.all Management API endpoint and moved programmatic log querying to a new, ClickHouse-backed logs endpoint.[1] Anyone with a script, log shipper, dashboard, or MCP-connected agent that calls .../analytics/endpoints/logs.all directly had two months of warning and, as of yesterday, no fallback. The migration itself is a real architecture change, not just a renamed path. But the changelog Supabase wrote to walk people through it contains a wrong column name in its own example query, one that a user flagged in a bug report a month before the deadline and that never got corrected.
What actually changed
Under logs.all, each log source, edge_logs, postgres_logs, function_edge_logs, and so on, lived in its own queryable table, and the SQL dialect was whatever Supabase’s older analytics layer accepted. The new logs endpoint collapses every source into one unified logs table and accepts ClickHouse SQL exclusively.[1][2] Nested request and response fields that used to require a CROSS JOIN unnest() per level of nesting against a metadata array now sit in a flat log_attributes map, read directly with bracket access: log_attributes['request.method'] instead of three chained joins.[1] That’s a real simplification once you know the new shape, and it matches a broader move: Supabase’s logs pipeline, previously built on Logflare with a BigQuery backend and one table per service, now runs on a single ClickHouse table.[3]
Supabase’s migration changelog, published July 23 as a two-month notice, lays out the fix in three steps: change the endpoint path from logs.all to logs, convert queries to ClickHouse SQL, and filter to a specific source instead of selecting its table. Its own example for that third step is:
-- After: filter the unified stream by source_name
SELECT timestamp, event_message
FROM logs
WHERE source_name = 'edge_logs'
ORDER BY timestamp DESC
LIMIT 100
source_name is not a column on the new endpoint.
The bug report Supabase never answered
On August 22, a month before the cutoff, a user filed a comment on the changelog’s GitHub discussion thread reproducing the failure on two separate projects. Querying select source_name from logs limit 1 against the live endpoint returns {"result":null,"error":"Field \"source_name\" does not exist."}. Querying select source from logs limit 1 instead returns {"result":[{"source":"postgres_logs"}],"error":null}. The full replacement query, source = 'function_edge_logs' in the WHERE clause instead of source_name, ran and returned rows identical to the old logs.all query.[4]
The same report flagged a second problem: there was no way to discover the endpoint’s schema from the endpoint itself. describe logs and select ... from system.columns both returned Backend error! Retry your query. rather than a schema listing, so the only way to find the right column name was to probe candidates one query at a time.[4] The user also noted that the error’s wording, Field "source_name" does not exist, doesn’t read like a raw ClickHouse error (ClickHouse’s own unknown-identifier error reads Unknown identifier), suggesting the endpoint runs its own query validator with a schema that had already been corrected to source, while the changelog and its own linked discussion thread were not. As of this writing, that comment has no reply, and the changelog text is unchanged from what it said in July.
Supabase’s separately maintained API reference for the new endpoint, last modified on September 23 itself, the day logs.all actually went away, settles it independently: “Filter by the source column to specify specific log sources, such as edge_logs, postgres_logs, etc."[2] Two Supabase-owned pages, updated on the same day, disagree with each other, and the one most people migrating a script would actually open, the changelog with the copy-pasteable example, is the wrong one.
Two more things the guide doesn’t flag
The default query behavior changed underneath scripts that never passed their own SQL. logs.all queried only edge_logs when no sql parameter was supplied.[5] The new logs endpoint, without an explicit sql parameter, queries API Gateway events only, which is the same practical default but is worth checking explicitly if any caller relies on it rather than always sending SQL.[6] And the endpoint enforces a hard 24-hour window on iso_timestamp_start/iso_timestamp_end, rounded to the nearest minute; a caller that walks a longer range needs to fetch it in separate windows and combine results client-side, not extend the range in one call.[2][6]
The MCP angle is easy to miss if you don’t run an AI agent against your database, but it’s the same underlying break: the Supabase MCP server’s get_logs tool called logs.all internally, so any agent still on mcp-server-supabase before v0.10.0 lost log access on the same day, silently, unless it had already been upgraded.[1][7] That release, shipped August 10, added a query_logs tool as an explicit breaking change and fixed a related bug in how it selected the SQL dialect for log queries, which suggests the ClickHouse migration was still shaking out client-side details a month after the tool shipped, not just on the server side.[7]
The decision this changes
None of this is exotic. A vendor deprecated an endpoint, gave two months’ notice, and wrote a migration guide, which is more process than plenty of breaking API changes get. The failure is narrower and more common than “the API changed”: the specific worked example in the official migration instructions used a column name that fails against the actual backend, a different Supabase-owned page already knew the right one, and a user’s bug report sat unanswered through the deadline it was warning about.
The practical habit this argues for isn’t distrust of vendor changelogs generally. It’s not shipping a migration for a breaking API change straight from a copy-pasted example without running it once against the real endpoint first, and checking whether the vendor has a second, independently maintained reference (an OpenAPI spec, an SDK, a “reference” page distinct from the “guide” page) that might disagree with the walkthrough. Where a schema-discovery query exists, use it before trusting either document. Here, that path was also broken, which is exactly the situation where a five-minute manual probe, select <candidate_column> from logs limit 1, catches what the guide didn’t.
Sources
[1] https://supabase.com/changelog/48235-migration-of-supabase-management-api-logs-all-analytics-endpoint-to-logs-endpoint: Supabase changelog #48235, published July 23, 2026
[2] https://supabase.com/docs/reference/api/v1-get-project-logs: Management API reference for the logs endpoint, last modified September 23, 2026
[3] https://supabase.com/docs/guides/observability/advanced-log-filtering: “Query logs with SQL” guide, published September 23, 2026
[4] https://github.com/orgs/supabase/discussions/48235: GitHub discussion #48235, comment from julhug16, August 22, 2026
[5] https://supabase.com/docs/reference/api/v1-get-project-logs-all: Management API reference for the deprecated logs.all endpoint
[6] https://supabase.com/docs/reference/api/v1-get-project-logs: query parameter and timestamp-range documentation
[7] https://github.com/supabase/mcp/releases/tag/mcp-server-supabase-v0.10.0: mcp-server-supabase v0.10.0 release notes, August 10, 2026