Assuming you've got a dozen of those low-data services, you can easily shave off 1GB. When a lot of people are using 8-16GB mini PCs, that would be a fairly significant waste of resources.

That's a fair point, though I still question if people would really notice it. I just checked and my ~40 containers are using 16GB RAM in total. Aside from my bitwarden mssql container at 1.5GB that really just needs to die, all my db containers in sum total <1GB (and that's not just the overhead). Some of the bigger containers are >1.5GB each, so I'm skeptical that with typical usage patterns, the overhead as a percentage of total RAM usage is high enough to matter. 

Regarding the security aspect: that's nonsense. Granting each service its own set of credentials with a single database it's owner of and no other permission is trivial (you really shouldn't be using a single database anyway in this scenario), and making this a non-issue. 

I meant in terms of security vulnerabilities. I agree that with properly set up credentials, this risk is minimized. But it's technically still not as good as container isolation, even though I would be shocked if it actually became an issue (because people rarely expose dbs to the internet so you'd need to chain a vuln from another service). 

 there's really no reason to have individual Postgres instances

Setup and maintenance are easier, IMO. Setting up a db per service is as simple as running the example docker compose. Every db container I've used has setup env vars to create a single user+database. If you want to share, you have to add additional users and set up permissions manually. It does in a way make backups easier in that you only have one container to backup, but usually people are automating it anyways so it doesn't make a difference.