Just considering the backup piece, I feel like this could lead to problems. Right now we use instance level backup jobs which loop through all the databases sequentially and back them up one at a time. What happens if each database contains its own backup job and they are all scheduled to start at exactly the same time? That could really put a strain on both the disks that hold the mdf files and the location where the backup is being written. I also feel like that would be complicating one of the parts of our jobs that are rather simple now. DBAs know which databases in an instance need which kinds of backups, and can manage them together. If the backups were managed at the database level, we suddenly have 10s, 100s, or even 1000s of individual backup jobs and schedules to maintain.
Easily. Microsoft could add logic that allows jobs with the same name to be scheduled sequentially.
Don't forget, this isn't something you manage and maintain constantly. How often do you revisit backup jobs and schedules? How often do you move databases? It's rare.
I can imagine quite a flexible constraint system based on time, whether the database has (non-system) peers on the instance, signals/events, specifying whether parallelism is allowed or not, etc. These rules should be specified within the contain with values, events and signals passed in to each container to evaluate.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!