[JonathanBeuys]

Only when your application depends on optimizing your database to the max.

Most applications don't.

And even if the application I work on does - then only in production. Not on my laptop. So on my laptop I will simply chose a docker image that resembles production as closesly as possible. I will not use a VM.

[KaiserPro]

> Only when your application depends on optimizing your database to the max.

Only when you don't need to store data for any length of time. The point of containers is that they don't store state. You have to manage that.

And for some cases you can get away with it. But for most websites, keeping a single container up for many years isn't a great strategy. (Yes, I know there are ways around this. but they are not as simple as "docker run postgres")

[xorcist]

Trivial use cases are generally trivial.

[koolba]

The vast majority of use cases for databases are trivial. For every esoteric, optimized to the max, bleeding edge kernel parameter tuned environment, you have 10,000+ CRUD apps that do little more than primary key look ups on vanilla btree indexes.

[therealdrag0]

I’ve worked at a half dozen companies most people have never heard of and they all had database complexity and performance issues. The whole “only FAANG has scale” meme needs to die.

You’re probably right there’s a magnitude more tiny apps but who cares. A large number of us still are interested in and need to solve for non-trivial cases.

[Too]

Most database performance issues are bad choice of indices, bad data model, bad queries, not enough RAM, missing pooling, unrealistic expectations and lack of pre-computed caches.

None of these are solved by "optimize kernel-parameters to the max".

[therealdrag0]

I agree! I must have misread or misunderstood the context.

[koolba]

This is exactly what I was talking about.