You can scope the DDL permissions to a single schema while still using the same database (and benefit from all the transactional guarantees a single database offers).

Yes, if database supports it (I guess every major ones now do) then it's great. Postgres's transactional DDL seems like great fit.

I'm sorry, I don't follow.

I was talking about an application and its accompanying database, which would still be paid for and administered by the customer, not a database outside the application which it would be accessing.

That still raised many eyebrows.

I think the GP was assuming the reason sysadmins worry about running DDL is the danger of overwriting/modifying tables the application depends on.

If this is the main concern, you could have two databases (or schemas, if your database supports it).

One for application configuration/storage that the application never runs DDL on and another for user data, where the tables can be created/modified dynamically.

That separation means that, at worst, user data is screwed up if there's a bug in the DDL generation, but the application should still be able to run.

At least, that was my read.