Unbundling Auth from Supabase

This points to auth, not the database, as the first place Supabase can stop feeling like a simple all in one backend and start feeling like a tradeoff. In this case, the company still runs core data, storage, and customer isolation on Supabase, but it has considered splitting auth out because identity is where enterprise and government apps often need the most custom behavior, policy control, and infrastructure flexibility.

• The team uses Supabase for PostgreSQL, storage, and auth, calls auth equally central to the database, and says moving off the stack would take months. That makes any auth change a surgical unbundling, not a full replatform.
  1 sacra
• Their customer isolation model uses row level security in one shared database. That means the database side is working well enough, while the friction appears concentrated in login, session, and identity flows rather than tenant separation or core data storage.
  1 sacra
• This is exactly where dedicated auth vendors win. Bundled auth from platforms like Supabase competes on convenience, while companies like Stytch expand by offering deeper customization and migration tools once apps outgrow the default login layer.
  2 sacra 3 sacra

The likely path is a more modular stack, with Supabase staying as the system of record and auth moving out only for customers with stricter identity requirements. That keeps the operational speed of managed Postgres and storage, while letting identity evolve into a separate control point for larger and more regulated deployments.