Inside LuBot's database-per-tenant architecture

LuBot, a solo-founder business analytics chat SaaS, moved from shared Supabase tables to a database-per-tenant architecture to provide stronger customer data isolation across its 52 tables and four schemas. Supabase remains the control plane for organizations, users, and billing, while Neon creates an isolated Postgres branch for each paying customer through a Stripe webhook, runs migrations, stores the connection URL, and routes subsequent requests to that tenant’s database. Deterministic branch names prevent duplicate provisioning during webhook retries, while a centralized tenant resolver ensures application code consistently selects the appropriate database. Neon’s serverless autoscaling and scale-to-zero capabilities make the approach economical by suspending inactive tenant compute after 300 seconds while retaining storage. The implementation also uses Neon’s PgBouncer-backed pooled connections for application traffic, direct connections for migrations and session-dependent tasks, and careful handling of search paths and connection resets to avoid state leakage between requests.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.