A single database, while simple in terms of the number of boxes drawn on an architecture diagram, brings it’s own complexities specifically in terms of:

Scalability – it’s much easier to scale horizontally with many small databases.

Data security and isolation – a thorough Sarbanes-Oxley or PCI audit may not like your data being lumped in the same database as every other company.

Versioning – depending on your business, it may not be appropriate to move all clients onto new versions simultaneously.

Relational modelling – for those businesses where the ACID model is still important, a single database tends to compromise your ability to design formal normalised databases.

I’m not sure who benefits from attempting to apply narrow definitions of ‘what is SaaS?’ or ‘what is the cloud?’, but I don’t think it’s the consumer.

Architectural complexity is not, of itself, a bad thing. It can be governed by a properly versioned service oriented architecture, tool support and, more importantly, exhaustive automated testing.

The burden in terms of infrastructure, support and maintenance, etc is immense – and unless clients are large enough (or generate enough revenue) to justify this, it’s just not sustainable or scalable.

I’d possible argue (petty point, though) that it’s not true SaaS – it’s a publically available, private installation of a software package. Moot, I know. 🙂