Supabase as 2012 BaaS

This frames Supabase as a convenience bundle, not a programmable infrastructure layer. The old BaaS model won by letting a small team click together database, auth, and storage fast, but it assumed the product itself was the backend. In this interview, the friction shows up when teams want repeatable setup, single tenant isolation, private cloud deployment, or all infrastructure captured cleanly in Git, which is where container stacks, Firebase, and Neon fit better.

• Firebase and Parse were the original template. They gave developers drop in backend primitives during the mobile and SPA shift, when avoiding server setup was the main win. Calling Supabase a 2012 style product places it in that lineage of bundled backend services rather than modern infrastructure first tooling.
  2 sacra 4 sacra
• The practical complaint is not Postgres itself, it is control surface. In the interview, the team prefers giving each customer or developer a separate cloud project or account, then defining auth, tests, and infra in code. Supabase projects are described as harder to create, audit, and evolve that way, while Neon is used as a narrower Postgres layer inside a more portable stack.
  1 sacra 3 sacra
• That difference maps to market positioning. Supabase sells a full backend with auth, storage, and realtime on top of Postgres, while Neon focuses on Postgres as a service. Supabase has still grown fast because AI app builders need an instant backend, but that growth is strongest where users want one stop setup, not maximum infrastructure flexibility.
  2 sacra 3 sacra 4 sacra

Going forward, the line will sharpen between backend bundles for fast app generation and infrastructure layers for teams that want portability and code level control. Supabase is well positioned if it becomes the default backend under vibe coding tools. The deeper production stack for experienced teams is likely to keep unbundling into pieces like hosted Postgres, native cloud auth, and containers.