[OJFord]

I think that was confusingly written, but what it means is 'k8s recommends not using it for database, but in Nomad is fine' - the EC2 instances are just nodes like any other, but 'tagged for db'.

And if self-hosting Nomad on AWS is (allegedly) so much easier than operating managed k8s (EKS), isn't that more damning rather than less?

The all-in AWS answer I suppose would be ECS. I quite like it but I think for anything beyond small, more than a few services part of the same system, I can understand wanting to run Nomad (or use EKS) instead.

[GauntletWizard]

You can run databases that way in K8s as well. Nobody does, because it's a terrible abstraction for high availability of conventional databases. The operator pattern does the opposite of help, creating more moving parts.

The problem with running databases yourself is that it's hard to run databases, and having dedicated physical hardware works, until it doesn't. Nomad make it easy to run dedicated physical hardware for it. As soon as you have a failed EBS volume with your DB on it. Failed EBS volumes still happen frequently, though we've mostly obviated the problem by using managed dbs.

[Semenoto]

I'm running plenty of PostgreSQL in k8s.

Know a few people who run hundreds of them too.

And it's perfect for dev shit were colleges pull in their PostgreSQL themselves until later through helm dependencies

[GauntletWizard]

Oh, yeah - If you don't care about data availability/uptime, databases in k8s can be magical. It's just not suitable for high availability out of the box - Postgres, not k8s.

[OJFord]

I'm not defending the position, I've never used Nomad (though been wanting to, at home) but have used k8s, including in-cluster database. I was just explaining what the article was saying, because I think 'Nomad, plus EC2 for the db' is a misreading.