Supabase exposes your database directly to the client?
RLSI’m not an engineer or developer. I used ChatGPT and Claude to research a modern backend stack for a CTV/VOD app that could eventually support six platforms: web, iOS, Android, tvOS, Roku, and Fire TV.
The suggested stack was:
Sanity for content management and video asset management UI
Mux for video encoding, storage, delivery, analytics, and live streaming
Vercel for Next.js hosting and edge functions
Cloudflare for DNS, DDoS protection, and WAF
Supabase for database, auth, realtime, and user management
PostHog + Sentry for analytics and error monitoring
I shared this with an engineer friend, and he said the architecture relies too heavily on Postgres Row Level Security policies instead of a proper backend service layer. In his view, that may work for a simple CRUD app, but for a multi-platform OTT product with live events, athlete payouts, SSAI, and six client targets, it could become difficult to maintain.
He also said Edge Functions are not a true backend for this level of complexity, and that debugging auth and business logic across platforms becomes painful when too much logic lives in RLS policies. His recommendation was a proper backend service layer, specifically NestJS with TypeScript, while keeping Postgres as the database and accessing it through Prisma rather than directly from the client.
I then shared that feedback with Claude. Claude agreed that NestJS with Prisma is better at scale, but said this sounds more like year 2–3 architecture than day 0. His view was to keep the MVP lean, ship faster with Supabase, and only migrate once real traction justifies the added complexity.
My questions are:
1. Is Claude’s take correct?
2. Besides Supabase, are there other database options that work well with Mux?
3. Does this stack look solid for a modern, scalable VOD backend?
Thank you!
The suggested stack was:
Sanity for content management and video asset management UI
Mux for video encoding, storage, delivery, analytics, and live streaming
Vercel for Next.js hosting and edge functions
Cloudflare for DNS, DDoS protection, and WAF
Supabase for database, auth, realtime, and user management
PostHog + Sentry for analytics and error monitoring
I shared this with an engineer friend, and he said the architecture relies too heavily on Postgres Row Level Security policies instead of a proper backend service layer. In his view, that may work for a simple CRUD app, but for a multi-platform OTT product with live events, athlete payouts, SSAI, and six client targets, it could become difficult to maintain.
He also said Edge Functions are not a true backend for this level of complexity, and that debugging auth and business logic across platforms becomes painful when too much logic lives in RLS policies. His recommendation was a proper backend service layer, specifically NestJS with TypeScript, while keeping Postgres as the database and accessing it through Prisma rather than directly from the client.
I then shared that feedback with Claude. Claude agreed that NestJS with Prisma is better at scale, but said this sounds more like year 2–3 architecture than day 0. His view was to keep the MVP lean, ship faster with Supabase, and only migrate once real traction justifies the added complexity.
My questions are:
1. Is Claude’s take correct?
2. Besides Supabase, are there other database options that work well with Mux?
3. Does this stack look solid for a modern, scalable VOD backend?
Thank you!
