Supabase's October 30, 2026 change revokes default Postgres GRANTs on new `public` tables so the Data API cannot see them, it leaves RLS behavior untouched, and it has already been the default for every new project since May 30, 2026

An 81.711995 s QuickTime/MP4 (mov,mp4,m4a, major brand isom, minor version 512, compatible brands isomiso2mp41, encoder tag Lavf58.76.100) carrying one HEVC video stream (Main profile, level 120, hvc1 tag, 720x1280, 9:16, yuv420p, bt709 primaries and transfer, tv color range, 30/1 fps, 2450 frames, 312,796 bps, 81.666667 s) and one HE-AACv2 audio stream (44.1 kHz stereo, 48,094 bps, 1763 frames, 81.711995 s), for an overall 367,461 bps and 3,753,253 bytes on disk; yt-dlp recorded format id bytevc1_720p_367457-1, and the container carries TikTok's own tags comment=vid:v12300gd0001dbb3ra7og65jel3qflf0 and vid_md5=df24e13c9c89cfbc90df783f7cf41a57, with no aigc_info AI-labelling field present at all. Posted at epoch 1792425383, which is 2026-10-19T15:56:23Z and 10:56:23 CDT, by handle ducktate.com (uploader id 7665287672349737997, nickname Chris Ducktate), with the audio credited as track "original sound" by artist "Chris Ducktate", which is TikTok minting a sound from the uploader's own audio rather than serving a catalogue track. The description runs 77 characters and 14 words, carries zero hashtags and zero mentions, and its only non-ASCII character is a U+2019 right single quotation mark in "don't". At capture time, which the metadata.json mtime puts at 2026-10-20 00:02:06 local and the embedded epoch field at 1792472526 or 2026-10-20T05:02:06Z, roughly thirteen hours after posting, the counters read 5,648 views, 202 likes, 18 comments, 35 reposts and 187 saves. I read twenty-one of the forty-one extracted frames, numbers 001, 004, 005, 006, 011, 014, 015, 016, 017, 018, 019, 021, 023, 024, 025, 026, 028, 030, 032, 033 and 041, which at the 2 s extraction interval sit at 0, 6, 8, 10, 20, 26, 28, 30, 32, 34, 36, 40, 44, 46, 48, 50, 54, 58, 62, 64 and 80 seconds. They show one continuous handheld vertical talking-head shot of a bearded man in a white cap, clear-framed glasses and a blue polo with a grey collar, seated at a desk with a white-and-grey mechanical keyboard, a lavalier transmitter clipped to his collar, a black "US Nation" mug, an acoustic guitar on a navy wall behind him and a ceiling fan overhead, with burned-in single-word karaoke captions running the whole length. Three overlays sit on top of it. Frame 001 at 0 s carries the green-and-white supabase wordmark above white block text reading "UPDATE COULD BREAK YOUR APP". Frames 004 through 006, at 6 to 10 s, carry an arched yellow-and-orange series card reading "SOFTWARE ENGINEERING FOR VIBE CODERS". Frames 015 through 018, at 28 to 34 s, carry a macOS screenshot of the creator's own Ducktate app, absent at 014 and at 019, and frames 024 through 032, at 46 to 62 s, carry a Google AI Overview card, absent at 023 and at 033; both are transcribed verbatim in the sections below. The transcript holds 278 words across 25 segments, and it contains a clear past-the-end hallucination: segment 24 runs 80.80 s to 81.56 s with "I will see you tomorrow", and segment 25 repeats the identical sentence from 81.56 s to 111.54 s, which is 29.777 s past the 81.763265 s extracted audio.mp3 and 29.828 s past the 81.711995 s AAC stream. The spoken video ends once, not twice, and nothing in that final segment should be quoted.

The mechanism is Postgres GRANTs on default privileges, and Supabase states in one line that RLS is untouched

The transcript says "permissions" six times and never names the mechanism. At 34.34 s it collapses two different things into one phrase: "if I didn't have any row-level security or the correct permissions set". Supabase's own changelog separates them in a single sentence. The entry titled "Breaking Change: Tables not exposed to Data and GraphQL API automatically", published 28 April 2026, says: "RLS behavior remains unchanged. Grants are a separate layer: they control whether a role can access a table at all, while RLS controls which rows that role can see."

What actually changes is Postgres default privileges on the public schema. Supabase describes the old behavior as "when you create a Supabase project with default settings, select, insert, update, and delete are granted to every table in the public schema to the anon, authenticated and service_role roles." The new behavior removes that automatic grant. The changelog publishes the exact statements the dashboard runs, and they are alter default privileges revokes rather than anything RLS-shaped:

alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;

Supabase's own before-and-after table makes the separation explicit. Against the row alter table ... enable row level security it prints "Remains the same", and against create policy ... it prints "Remains the same". Only the grant row changes, from "Implicit, via default privileges" to "Required, explicit grant statement".

The failure mode is a specific Postgres error rather than an empty result. The changelog quotes the PostgREST response verbatim as "code": "42501", "message": "permission denied for table your_table", with a hint reading "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;". Supabase says it designed that hint for machines: "The PostgREST error response above includes a precise hint, so an agent can self-correct when a grant is missing instead of producing a broken request."

October 30 is the third of three dates, and for any project created since May 30 this is already live

At 46.26 s the video says "with Supabase's new update, after October 30th, any new tables created in Supabase will automatically have to have these permissions set." The date is right and the framing is wrong. October 30, 2026 is the last milestone of a rollout that started six months before this video posted.

Supabase's published rollout table gives three dates. On 2026-04-28 the changelog went live and an opt-in toggle appeared at project creation, labelled "Automatically expose new tables" in one passage of the entry and "Automatically expose new tables and functions" in another. On 2026-05-30 "the new behavior becomes the default for all new projects", described as "a gradual rollout over a few weeks to monitor impact". On 2026-10-30 "the new behavior is enforced on all existing projects". A fourth date sits in between: on 2026-05-18 pg_graphql stopped being enabled by default.

That means a viewer who spun up a Supabase project at any point in the roughly five months before this video was posted is already in the new regime, and nothing about October 30 is pending for them. The video addresses only the existing-project cutover and presents it as the single date. Supabase maintainer @lukas-bernert put the actual scope plainly in the GitHub discussion on 29 May 2026: "You do not have to do anything for existing tables in existing projects. However, if you do create NEW tables in public in new or existing projects, after October 30th, you need to add explicit GRANTs."

The date itself is confirmed rather than slipping. The discussion thread for the changelog carries no staff announcement of a delay, and Supabase's published communications timeline still schedules a "final notice, one week before change for existing projects" email for 2026-10-23, three days after this video was posted.

"Nobody can see it" is bounded to the Data API and to the `public` schema

At 55.40 s the video says the table "is going to be private, which means nobody can see it. Not even authenticated users, unauthenticated users, anybody." The direction is right and the boundary is missing, and the missing boundary is the part that decides whether a given app breaks.

Supabase scopes the change to its auto-generated REST and GraphQL layer. The changelog says the change "applies to projects that use the Data API, Supabase's auto-generated REST and GraphQL layer, which is what supabase-js and our other client libraries call", and then rules out the other path outright: "If your app reads and writes Postgres over a direct connection (via psql, ORM or an app server with a connection string), this change will not affect you." Its "Who is affected" section opens with "You are unaffected if you only talk to your database over a direct Postgres connection--you can stop reading."

The schema boundary is just as hard. Supabase's FAQ asks whether storage, auth, realtime or custom schemas are affected and answers "No. The change touches default privileges in the public schema. Tables in storage, auth, realtime, and any custom schemas you expose via the Data API keep their current grants and their current defaults."

One part of the video's phrasing is stronger than it sounds and turns out to be correct. The revoke statements strip service_role alongside anon and authenticated, so a secret-key call routed through PostgREST hits the same 42501 as an anonymous one. The video's "not even authenticated users, anybody" captures that, even though it reaches the right answer without naming the role.

The break framing also needs narrowing. Existing tables survive the cutover. Supabase says "Existing tables are not affected in your project, they keep their current grants and stay reachable", and maintainer @steve-chavez confirmed on 20 July 2026 that existing tables in existing projects are "not automatically affected because they already have the required grants." What breaks is the next table somebody adds. Supabase makes exactly that point about projects that look clean today: "After October 30, any new table created in public without an explicit grant stops being reachable via the Data API, so a project with no flagged tables today still breaks the first time someone adds a new one."

The "right now anyone could read and write" premise holds for the SQL editor path and fails for the dashboard path

At 11.68 s the video sets up its stakes: "Right now, if you created a new table in Supabase for your user's data, but you forgot to set any of the security permissions, anyone on the internet could read and write to that table without even being locked in." That last phrase is a Whisper slip for "logged in". The claim underneath is true for one of the two ways to create a table and false for the other, and the video treats them as one.

Supabase's "Securing your API" guide draws the line directly: "Tables created through the Supabase Dashboard have RLS enabled by default." Tables created through the SQL Editor or through migrations do not get that, and need alter table your_table enable row level security; run against them explicitly. A table with RLS on and no policies returns nothing to anon or to authenticated, so the dashboard path does not produce the world-readable table the video describes. The SQL editor path, a migration, a CLI script or an AI coding agent issuing raw create table does, because today's default grants attach and no RLS stands in the way. Supabase labels that outcome with a Danger callout: "Tables and views exposed through the Data API without RLS can be accessed by any role with matching grants."

The reachability half of the claim is also real rather than theoretical. Supabase designs the publishable key to ship in client code, calling it "Safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code", and says of it that "Anyone can read it, so it only reaches what Row Level Security allows" and that "Row Level Security decides what this client can reach, so enable it on every table before you deploy." A key anyone can read plus a table with grants and no RLS is the condition the video is describing, and the key is public by design.

Worth noting that Supabase's own stated reason for the October 30 change is this exact gap. The changelog says the old model assumed human review, that "Today, agents, CLI scripts, and AI platforms create tables too, and many of those operations do not have a human reviewing the diff", and that the change holds "regardless of how you created it (SQL editor, migrations, Management API, MCP, CLI, or an AI coding tool)". So the video is describing a genuine hazard and then describing its fix as the danger.

The "your AI is not going to know" claim is unfalsifiable as stated, and the video's own screen contains a counterexample

At 64.18 s the video says "More than likely, your AI is not going to know that, so it may not even add those permissions, which is going to break the new features that you're building then." No one can verify a negative across every coding tool, every model and every retrieval path, so this stays unverified rather than wrong. What is checkable is whether Supabase published guidance aimed at AI coding tools, and it did, well before this video.

Supabase shipped Agent Skills on 9 April 2026, nineteen days before the changelog, under the title "AI Agents Know About Supabase. They Don't Always Use It Right." The post names the failure modes it is built to prevent, including agents that "ignore the docs entirely, relying on training data that may be months out of date", and it supports "Claude Code, Codex, GitHub Copilot, Cursor, or any of the agents that support Agent Skills Open Standard" with a one-line install, npx skills add supabase/agent-skills. The changelog then routes readers straight at it: "If you use an AI coding tool to create tables, update its system prompt or adopt the Supabase agent skill, which includes the grants step, and which we keep updated as the platform changes." Supabase also added the self-correcting PostgREST hint quoted earlier for the same reason.

The counterexample is on the creator's own screen. Frames 024 through 032, which sit at 46 to 62 s and cover the exact stretch where he delivers the October 30 claim, carry a Google AI Overview card reading in full:

To create or update tables in Supabase, you have two main approaches: using the visual Table Editor dashboard or running queries in the SQL Editor.

Additionally, note a critical 2026 security update: new tables in the public schema no longer expose their CRUD APIs automatically to client libraries like supabase-js. You must explicitly grant access roles.

That card is more accurate than the voiceover running underneath it. It names the public schema, names the Data API surface via supabase-js, uses the present tense that matches the already-live new-project default, and says "grant access roles" where the voiceover says "permissions". An AI surface that the creator himself put on screen knew about the change and described the mechanism correctly, in the same frames where he says AI probably will not know.

The card is also the strongest single piece of evidence that the transcript's vendor name is a Whisper artifact. Whisper renders it "Superbase" in all five spoken instances. The Google card prints "Supabase", and the opening overlay at frame 001 shows the official green-and-white supabase wordmark.

The app is "Ducktate" with a k, and Encryption Mode is a paid opt-in rather than a property of every user's notes

Whisper renders the creator's product as "Ductate" at 27.78 s. The handle ducktate.com already suggests otherwise, and two independent sources settle it. The frames are the first: the macOS screenshot in frames 015 through 018 shows a sidebar wordmark reading "Ducktate" beside an orange duck glyph, and the burned-in caption at frame 015, 28 s, spells "DUCKTATE" in block capitals. The second is the product's own site, which calls itself Ducktate and heads its homepage "Everything you say, hear, and type, in one place" under the tagline "Markdown notes you own, ready for your AI agents".

The encryption claim needs narrowing. At 31.02 s the video says the notes table "stores all of the encrypted notes for all of my users", and at 42.60 s "Luckily, I encrypt a note, so it's not a big deal". Ducktate's own pricing page puts encryption behind the paid tier. The Free tier at $0 lists dictation, local transcription, "Notes on your Mac, no limit" and AI cleanup with your own Claude or ChatGPT key. The Pro tier at $9.99 per month or $99.99 per year adds "Cloud notes accessible on web, iPhone, and all Macs" and, in the same line, "Ducktate AI, local AI, and Encryption Mode". Encryption is a named mode on a paid plan, not a blanket property of every row. Free-tier notes stay on the user's Mac and never reach the cloud table at all, so "all of the encrypted notes for all of my users" overstates both the coverage and the default.

The demo instance on screen reinforces that. Across all four Ducktate frames the sidebar's bottom entry reads "Sign in", meaning the session is signed out, and the status bar reads "2 notes", "Vault synced just now", a green "Local mode" indicator and "Whisper small en". The app being shown while he describes a cloud notes table is running in local mode against a local vault. The visible content is placeholder: an "All Notes" list at frame 015 holding two notes dated Oct 15, "other" with the body "Other note body that must stay as is" and "plan" with "The launch plan has three steps", then at frames 016 through 018 the "plan" note open in a tab, going from "0 words, 0 characters, 0 backlinks, 1 properties" at 30 s to "7 words, 83 characters, 0 backlinks, 4 properties" at 34 s as the string "kiwi-edit" is typed in. A code editor sits behind the window showing a partial line, "...the current plan, open tasks, wave state, ticket ids, branch and", and a title bar reading "MCP tools (optional)" with "138 ms". None of it is a Supabase dashboard, and no table, policy, grant or SQL statement appears in any frame of this video.

Key Takeaways

Correction: The change alters Postgres default privileges, revoking select, insert, update and delete on new public tables from the anon, authenticated and service_role roles. Supabase's changelog states "RLS behavior remains unchanged" and prints "Remains the same" against both enable row level security and create policy in its before-and-after table. The video's "permissions", and its pairing of "row-level security or the correct permissions", conflate two separate layers.
Partial correction: October 30, 2026 is correct but is the last of three dates. The opt-in toggle shipped 2026-04-28, the behavior became the default for all new projects on 2026-05-30, and 2026-10-30 enforces it on existing projects. Anyone whose project was created in the roughly five months before this video posted is already in the new regime.
Correction: "Nobody can see it" applies to the Data API only. Supabase says the change "will not affect you" if the app reads and writes Postgres over psql, an ORM or a connection string, and its FAQ exempts the storage, auth, realtime and custom schemas entirely.
Verified: "Not even authenticated users" is right, and understates itself. The published revoke statements strip service_role as well, so secret-key calls through PostgREST hit the same 42501 error.
Clarification: Existing tables do not break. Supabase says they "keep their current grants and stay reachable", and maintainer @steve-chavez confirmed on 2026-07-20 that they are "not automatically affected because they already have the required grants." The breakage arrives with the next new table.
Partial correction: The "right now anyone could read and write" premise depends on the creation path. Supabase's docs say "Tables created through the Supabase Dashboard have RLS enabled by default", so the dashboard path does not produce a world-readable table. The SQL Editor, migrations, CLI and AI-agent paths do, because default grants attach and RLS does not.
Unverified: Whether AI coding tools know about the change. That negative cannot be checked across every tool. The checkable fact runs the other way: Supabase published Agent Skills on 2026-04-09, the changelog explicitly tells readers to adopt it because it "includes the grants step", and the PostgREST error carries a hint built so "an agent can self-correct". The Google AI Overview card on the creator's own screen at 46 to 62 s states the change correctly while the voiceover says AI will not know it.
Correction: The vendor is Supabase. Whisper renders it "Superbase" in all five spoken instances, contradicted by the supabase wordmark at frame 001 and by the word "Supabase" printed twice in the Google card at frames 024 through 032.
Correction: The app is Ducktate with a k, not "Ductate". The in-app sidebar wordmark, the burned-in caption at 28 s and the product site all agree.
Partial correction: Encryption is not universal across the app's users. Ducktate's pricing page places "Encryption Mode" in the $9.99 per month Pro tier alongside cloud notes, while the Free tier keeps notes local on the user's Mac.
Context: The demo shown at 28 to 34 s is a signed-out Ducktate window in "Local mode" with two placeholder notes, not the Supabase-backed production instance being described. No Supabase dashboard, table, policy or SQL statement appears in any frame of the video.
Clarification: The transcript's final segment is a hallucination. "I will see you tomorrow" is recorded twice, the second instance spanning 81.56 s to 111.54 s against an 81.763265 s audio.mp3, an overrun of 29.777 s. The transcript's "without even being locked in" at 19.62 s is a slip for "logged in".

Resources

Breaking Change: Tables not exposed to Data and GraphQL API automatically, Supabase Changelog, 28 April 2026 is the primary source for every date, the alter default privileges ... revoke statements, the "RLS behavior remains unchanged" line, the 42501 error body and hint, the before-and-after table, the Data-API-only and public-schema-only scope, the FAQ exempting storage, auth, realtime and custom schemas, the rollout and communications timelines including the 2026-10-23 final-notice email, and the instruction to adopt the Supabase agent skill.
Breaking Change discussion #45329, Supabase on GitHub establishes that the 2026-10-30 date is confirmed with no announced delay, and carries the maintainer replies I quote: @lukas-bernert on 2026-05-29 on new tables in new and existing projects, and @steve-chavez on 2026-07-20 on existing tables already holding the required grants.
Securing your API, Supabase Docs establishes that "Tables created through the Supabase Dashboard have RLS enabled by default" while SQL Editor and migration-created tables require explicit enablement, carries the Danger callout about tables exposed without RLS, and describes the anon, authenticated and service_role grant defaults on existing projects.
API Keys, Supabase Docs establishes that the publishable key is "Safe to expose online", that "Anyone can read it, so it only reaches what Row Level Security allows", and that the secret key "bypasses every Row Level Security policy you have".
AI Agents Know About Supabase. They Don't Always Use It Right., Supabase Blog, 9 April 2026 establishes that Supabase published guidance aimed at AI coding tools before the changelog, the supported agents, the npx skills add supabase/agent-skills install, and the named agent failure modes including reliance on stale training data.
Ducktate establishes the product's spelling with a k, its positioning as a dictation and notes workspace, and its homepage headline and tagline.
Ducktate pricing establishes that "Encryption Mode" sits in the $9.99 per month Pro tier alongside cloud notes, and that the Free tier keeps notes local on the user's Mac.