[edwhitesell]

Came in to, worked on a SaaS product that did this in 2000 (it was around since '97/'98). I was doing new customer deploy and support, not direct development. It was running on MSSQL 97, I think, then moved to MSSQL 2000. It worked okay, but we moved away from that model in a "next gen" build around 2001/2002.

The biggest hurdles are in the things like configurations. You'll probably want to have one code base, and maybe even one deploy/package for web servers. However, you'll need different configurations for each customer (DB name, credentials, etc.) and a way to manage them, and a way to identify which customer an HTTP request goes to before you can process it. You can use things like host names in your web app, but you'll really end up wanting some kind of "request router" to manage everything...at that point, it's far easier to put everything in one DB and move on with revenue-generation.

[mhitza]

Thanks for the perspective. I actually think the complex parts you mention are relatively easy nowadays.

If I were to implement it today I would probably use a centralized authorization service "authentication gateway" with something like forward_auth in Caddy to "tag along" configuration data with the request (teams, instance landing page etc. including encrypted database configuration storage, encoded as a JWT) https://caddyserver.com/docs/caddyfile/directives/forward_au...

I think the hard part is having enough discipline within a team to mostly work with backwards-compatible database changes, the automation to make that seamless, and the will to be proactive with the possibilities of this setup.