For small databases (anything with ~< 10,000,000 rows), sure, it's probably fine. Other than that, no.
* Unless you are self-hosting K8s and thus have a large amount of control over the underlying storage, the amount of IOPS you're getting will be hazy at best. Tbf this is also true with every single DBaaS, because the latency on network storage is absurd, so IOPS become somewhat meaningless.
* Unless you have modified the CPU scheduling options [0] in K8s, you have no control over core pinning or NUMA layout. This is even worse due to the fact that your K8s nodes are probably multi-tenancy.
* By its nature, K8s is designed to host stateless apps. It is fantastic at doing this, to be clear. I love K8s. But a system where the nodes can (and should, if you're taking advantage of spot pricing) disappear with a few minutes' warning is not a great host for an RDBMS.
* Hot take: it makes provisioning a database even easier, which means people with even less understanding or care of how they operate will be doing so with reckless abandon, which means people like me have even more work to do cleaning up their mess. I am a big fan of gatekeeping things that keep companies afloat. If you want to touch the thing that every service is depending on, learn how it works first – I'd be thrilled to help you. But don't come in and just yolo a copy-paste YAML into prod and then start chucking JSON blobs into it because you can't be bothered to learn proper data modeling, nor reading RDBMS docs.
Re: [0], if you don't care about core pinning, then it's unlikely you're going to care about any of these other points, and you probably also don't understand (or care) how blindingly fast an RDBMS on metal with NVMe can be.
I am not a Luddite. To reiterate, I have administrated self-hosted and managed K8s professionally. I also run it at home. I just have strong opinions about understanding fundamentals (and not causing myself extra work by allowing people who don't care about them to run infra).
> it makes provisioning a database even easier, which means people with even less understanding or care of how they operate will be doing so with reckless abandon, which means people like me have even more work to do cleaning up their mess. I am a big fan of gatekeeping things that keep companies afloat. If you want to touch the thing that every service is depending on, learn how it works first – I'd be thrilled to help you
Couldn’t agree more.
Kubernetes and such tools do not make things easier, they just give you the illusion of it.
That is an excellent way of putting it. Abstractions makes you think you’ve got a handle on things, but when they break, now you have two problems – neither of which you’re probably equipped to solve.
When I was doing Econometrics at Uni, the lecturer wouldn't let us use the functions in the software that did the mathematics for us. He made us learn using Spreadsheets and doing the calculations manually, _then_ he let us use the automated functionality once we understood it.
> By its nature, K8s is designed to host stateless apps. It is fantastic at doing this, to be clear. I love K8s. But a system where the nodes can (and should, if you're taking advantage of spot pricing) disappear with a few minutes' warning is not a great host for an RDBMS.
Why is this a problem? A typical deployment will have multiple replicas, with (hopefully) small replication lag. Those should be able to be promoted to be the new primary within a minute.
> A typical deployment will have multiple replicas, with (hopefully) small replication lag. Those should be able to be promoted to be the new primary within a minute.
What happens within that minute to database writes?
Well, the problem is a little bit more complicated than just having replicas.
You cannot build operational procedures based on “hope”.
High replication lag occurs for many many reasons (and they are not a rare event, or something that you can prevent). As well as network partitions.
Replication and binary logs can get corrupted, there can be deadlocks, duplicated row errors, etc.
The thing is that database administration is a broad and complicated topic, a small mistake or the lack of understanding how these systems work can easily lead to huge data losses.
Ah yes, HN. You know there are billions of sites(wp mostly), LoB apps etc that run on 1 mysql/pg/etc instance right? Replicas are not typical and a tiny minority.
OP was talking about 'typical database setup' being a replicated db. It's not typical. Nor is the use of k8s for stuff outside HN and massive companies. Not that I mentioned k8s anyway.
