Supabase Made Crystal Clear · chapter 2: Architecture: One Postgres
Two reference architectures
2026-10-25
Client-direct makes Row Level Security the gate; thin backend puts your server in front and keeps Row Level Security as the second lock. The rest of the book names which pattern each recipe assumes.
Below: the paragraph from the book that builds this idea, then the diagram itself (Figure 2.4), and a recap. About a minute of reading.
Everything in this book fits one of two shapes, and you will choose per app, not per company. In pattern (a), client-direct, the browser or mobile app talks to the Data API with the publishable key, and Row Level Security is the authorization layer: there is no server of yours in the path. In pattern (b), thin backend, your own server (a Next.js server component, a FastAPI or Express app, an Edge Function) talks to Postgres and Auth with the secret key or a direct SQL connection, and Row Level Security is defense in depth: the second lock, still on, behind your code. Figure 2.4 draws both.
Recap
- The idea: Client-direct makes Row Level Security the gate; thin backend puts your server in front and keeps Row Level Security as the second lock.
- The picture: Figure 2.4, 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
