SQL from the Frontend: Viable or Not?
summary
Claim: exposing SQL to the client massively speeds early development but is not production-ready alone. Demonstrated tools and patterns: Neon Author, Postgres RLS protecting per-row access (RLS shipped 2016), PostgREST/Supabase-style proxies, and Drizzle-generated policies. Built examples: todo app and a Twitter/X-style chat with RLS rules that work for reads/writes but leave secrets and third‑party API calls unresolved. Operational gaps: need robust rate limiting, a query allowlist, and avoidance of large stored‑procedure business logic.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:54Frontend SQL architecture
- 4:50Traditional backend roles
- 10:12Can DBs replace backend logic
- 15:50PostgreSQL RLS explained
- 18:44Social network modeling with RLS
- 24:47PostgREST and Neon Auth
- 28:50Remaining challenges
- 31:02Hybrid architecture future
- 33:49Summary and future
- 34:58Q&A
related talks
29mApps, Stacks, and Frameworks: Avoiding “Shiny Object” Syndrome
31mWriting an interactive streaming SQL engine and pre-parser using Flink
15mReactifying your application
28mPanel Discussion: The GraphQL Production Roundtable
36mKnowing What You See - Let's Talk About Front-end Consistency
31mReimagining the frontend-backend divide thanks to GraphQL
51mBuilding a Realtime "Backend in a Box" with PostgreSQL and Vue
03mGraphQL Revolutionizing API Development
