Supabase Made Crystal Clear · chapter 2: Architecture: One Postgres
The key matrix
2026-10-13
Two current keys, two legacy keys, and the Postgres role each one becomes. The legacy JWT keys are deprecated by the end of 2026 (as of 2026-09-18).
Below: the paragraph from the book that builds this idea, then the diagram itself (Figure 2.3), and a recap. About a minute of reading.
As of 2026-09-18 a project has four kinds of API key, and only two of them are current. The publishable key (sb_publishable_...) is safe to ship: it becomes the anon role, or authenticated when a user JWT travels with it. The secret key (sb_secret_...) is server-only: it becomes service_role, which carries the Postgres attribute BYPASSRLS. The other two are the legacy anon and service_role keys, long-lived JWTs that play the same two parts. The docs are explicit about their future: "Supabase is deprecating the anon and service_role keys by the end of 2026. Use the publishable (sb_publishable_xxx) and secret (sb_secret_xxx) keys instead." Figure 2.3 puts the four side by side.
Recap
- The idea: Two current keys, two legacy keys, and the Postgres role each one becomes.
- The picture: Figure 2.3, from chapter 2 ("Architecture: One Postgres") of Supabase Made Crystal Clear.
- Go deeper: the chapter builds this step by step, with recipes and sources at the end.
This diagram is one of many in Supabase Made Crystal Clear.
Every chapter opens with the gist, draws the hard ideas, and ends with recipes and sources.
Get the book
