JDBC is not a protocol, JDBC is an API, hence the need for a different JDBC driver per RDBMS. I doubt the author is a developer, I see this misunderstanding often with architects who don’t code.
Not gonna lie, was expecting something with more substance. Instead I feel I just read a quimera of LLM slop with a homework assignment of some marketing kid trying his/her best to meet the quota.
Tech blogs demonstrate quality of engineering of a company and this blog post is just doing that. Uber eng org is probably so bloated that nobody really cares about this stuff anymore.
Horrible stuff really, half-way through between explaining the basics of MySQL and somehow merging that slop that into describing the architecture they are apparently using (+/- hallucinations).
100% AI for the cover photo. If you look at their other blog posts it looks like Uber eng doesn't care. They use lazy AI generated images (not even decent attempts at it) for all blog post cover images.
LLMs are basically trained to sound like mid-to-senior-mid-level Silicon Valley corporate blog-speak. It would not surprise me at all if Uber PR ran some this through some ghostwriting, I've seen that even at smaller places. Maybe it's even LLM-mediated now.
Uber offshored some parts of their engineering so all the new-ish blogs fit the stereotypes. Lazy written, LLM generated, by their offshore indian folks.
While I agree a subtle racist undertone is there, perhaps without intention (implying that all off-shored tasks will be done lazily), the more important part is that the article does really read like an LLM-generated slop (perhaps with some editing afterwards). Has all the typical 'markers', such as bloated text and overemphasized structure, etc. with the highlight for me personally being the "conclusion". It is so clear that the first paragraph was spit out by an LLM.
The bit with the implication that only offshore engineers would use LLMs to write blog posts, while the intellectually and morally superior engineers in the US would never stoop to such depths.
(Especially hilarious given it's Uber, which obviously could never have engineers doing anything morally dubious ever /s)
Things that are missing in most other proper databases, like transactional DDL. If you don't mind not having them, Mysql is fine. It's probably better than Postgres for mostly read databases, which is most uses. There was a time when Mysql was by far the most used but over the years it's growth has been fairly slow and Postgres has kept growing in use, mainly due to functionality and integrity.
People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources).
If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.
MySQL used to have some rather dodgy defaults way back and some people haven't touched it for decades and assume it's still like that. Also it got acquired by Oracle at some point and many people just hate Oracle. Finally it is now cool to love Postgres more, or sqlite.
MySQL is fine, boring tech that powers a great many companies. There's nothing wrong with choosing it for a new venture, but there's also nothing wrong with another choice. Which RDBMS you use won't be the deciding factor in your success these days.
MySQL 5 had bad defaults. Some would probably argue that hooking into sudo rather than a dedicated databaser user amounts to one. MySQL is also perceived by some to be a software for amateurs.
Unless you need the kind of sophisticated extensions Postgres supports MySQL is likely to be a good fit. The query planner is straightforward, performance tuning slightly more predictable and easy compared to Postgres.
same as php hate, mysql had some questionable design decisions and legacy hacks, which are mostly not that relevant today except for causing some warts on the interface (like e.g. utf8mb4, mysql_real_escape_string)
Kinda relevant as the article won’t really help - what would you use for HA MySQL in a non-Kubernetes setting? Getting automated failovers, deployment of new nodes, and ~50k databases?
Was about to say that we managed upwards of 4k servers worth of MySQL databases (as in 4k baremetal servers worth, not 4k small VMs each having a small MySQL) using "Orchestrator" at Booking.com ten years ago. I checked if it was still kicking before writing this and found that the GitHub repo was archived last year. The next Google hit I find is this article from three days ago:
Please do some additional research into the state of maintenance of that piece of tech before jumping on it. But it certainly did a lot of powerful things for us back in the day. The automatic promotion of followers was key to our deployment.
That, and patching MySQL in weird ways. I recall something about the filesystem layer being monkeyed with, because "who needs safe writes, it slows things down"
Well kinda. Galera looks like it's an amazing solution, and it can be for careful operators who read the docs, learn the new procedures and ensure that they're running workloads that fit well. It can eliminate the usual HA / replication / failover stuff. But it has the ability to act like a foot-machinegun.
Outside kubernetes where you don't have an kubernetes operator that can run the database cluster, spin up nodes and pods, manage volumes etc it's difficult to imagine how you might automate that infrastructure in addition to managing the database cluster, without building a lot of it yourself.
Percona MySQL (i.e. Galera), ProxySQL, keepalived, the flavour of orchestration that is most compatible with your production environment and team.
Make sure you up ulimit and systemd LimitNOFILE in the MySQL service config. Read docs closely, preferably bring on someone who's spent some time making mistakes in this area to help out, test diligently before putting into production, including load tests.
Discussion: https://news.ycombinator.com/item?id=42881012
Thanks
> using the JDBC™ protocol
JDBC is not a protocol, JDBC is an API, hence the need for a different JDBC driver per RDBMS. I doubt the author is a developer, I see this misunderstanding often with architects who don’t code.
The author is a "Chat GPT operator". Sadly, there is more and more such content hitting Hacker News.
Not gonna lie, was expecting something with more substance. Instead I feel I just read a quimera of LLM slop with a homework assignment of some marketing kid trying his/her best to meet the quota.
Tech blogs demonstrate quality of engineering of a company and this blog post is just doing that. Uber eng org is probably so bloated that nobody really cares about this stuff anymore.
I don’t get how this submission (and the identical one 17 days ago…) got upvotes, assuming anyone reads the article.
And no dup tag, flags?
Horrible stuff really, half-way through between explaining the basics of MySQL and somehow merging that slop that into describing the architecture they are apparently using (+/- hallucinations).
I'm not sure if it's just me, but it reads like a significant portion of this blog was written by a LLM.
Kinda does have that tone. Even the cover photo for the blog post has the classic AI generated look.
100% AI for the cover photo. If you look at their other blog posts it looks like Uber eng doesn't care. They use lazy AI generated images (not even decent attempts at it) for all blog post cover images.
"Cover Photo Attribution: The cover photo was generated using OpenAI ChatGPT Enterprise."
LLMs are basically trained to sound like mid-to-senior-mid-level Silicon Valley corporate blog-speak. It would not surprise me at all if Uber PR ran some this through some ghostwriting, I've seen that even at smaller places. Maybe it's even LLM-mediated now.
> At Uber, our MySQL®
> stateless services hosted in Kubernetes®
> using the JDBC™ protocol
> Percona™
> Cadence™
> Docker®
> Oracle InnoDB® engine within the mysqld process. We can configure this to use other MySQL engines like Meta RocksDB™.
Trademarks that obnoxious are off putting. The audience must not be engineers.
It also kind of reads as a “tldr but cool story bro” for engineers. Really looks like some paperwork had to be filled out.
RUN IT BACK https://news.ycombinator.com/item?id=42881012
Hey, how is Uber going to properly promote itself with only one article?
puts aluminum foil hat back on
Preface: not an american
Uber offshored some parts of their engineering so all the new-ish blogs fit the stereotypes. Lazy written, LLM generated, by their offshore indian folks.
Make of that what you want.
Without any proof you have resorted to some blatant racism. Sheesh
While I agree a subtle racist undertone is there, perhaps without intention (implying that all off-shored tasks will be done lazily), the more important part is that the article does really read like an LLM-generated slop (perhaps with some editing afterwards). Has all the typical 'markers', such as bloated text and overemphasized structure, etc. with the highlight for me personally being the "conclusion". It is so clear that the first paragraph was spit out by an LLM.
What part of that sentence is racist??
The bit with the implication that only offshore engineers would use LLMs to write blog posts, while the intellectually and morally superior engineers in the US would never stoop to such depths.
(Especially hilarious given it's Uber, which obviously could never have engineers doing anything morally dubious ever /s)
We use MySQL. Why? Well, it's hard to switch. And yes I believe Postgres is the better option, for us, and for almost anyone.
I was hoping to find some reason for Uber to use MySQL over the other popular FLOSS RDBMS (i.e.: Postgres).
For Facebook I more/less know what are their reasons. I was hoping to learn about Uber's reasons, but the article was was not going that deep.
https://www.uber.com/en-AU/blog/postgres-to-mysql-migration/
Who signed off on this crap?
Why MySQL? Why not Postgres?
Famously covered in this, controversial blog: https://www.uber.com/en-AU/blog/postgres-to-mysql-migration/
Largely truth, some small mistakes. Generally friends don't let friends use Mysql but at scale all the hacks and workarounds actually work.
> Generally friends don't let friends use Mysql
What drives this sentiment?
Things that are missing in most other proper databases, like transactional DDL. If you don't mind not having them, Mysql is fine. It's probably better than Postgres for mostly read databases, which is most uses. There was a time when Mysql was by far the most used but over the years it's growth has been fairly slow and Postgres has kept growing in use, mainly due to functionality and integrity.
People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources).
If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.
In 2025? Often a tribalistic ignorance of holding outdated preconceptions against MySQL.
A quick search hints me that there is still more ultra-large MySQL setups than there are PostgreSQL. By a large margin it seems.
Between easier upgrades/HA, thread connection model, Vitess and engines like MyRocks, it's hard to beat for many use cases.
MySQL used to have some rather dodgy defaults way back and some people haven't touched it for decades and assume it's still like that. Also it got acquired by Oracle at some point and many people just hate Oracle. Finally it is now cool to love Postgres more, or sqlite.
MySQL is fine, boring tech that powers a great many companies. There's nothing wrong with choosing it for a new venture, but there's also nothing wrong with another choice. Which RDBMS you use won't be the deciding factor in your success these days.
MySQL 5 had bad defaults. Some would probably argue that hooking into sudo rather than a dedicated databaser user amounts to one. MySQL is also perceived by some to be a software for amateurs.
Unless you need the kind of sophisticated extensions Postgres supports MySQL is likely to be a good fit. The query planner is straightforward, performance tuning slightly more predictable and easy compared to Postgres.
same as php hate, mysql had some questionable design decisions and legacy hacks, which are mostly not that relevant today except for causing some warts on the interface (like e.g. utf8mb4, mysql_real_escape_string)
On big reason why many choose MySQL over Postgresql is this MySQL extension https://github.com/vitessio/vitess
Thanks for actually answering the question!
Solutions like this also exist for PG, any insight into why vitess is better?
Because as tech people, we love transitive hate of technologies. We love to hate something because some blogger hates it.
Kinda relevant as the article won’t really help - what would you use for HA MySQL in a non-Kubernetes setting? Getting automated failovers, deployment of new nodes, and ~50k databases?
Was about to say that we managed upwards of 4k servers worth of MySQL databases (as in 4k baremetal servers worth, not 4k small VMs each having a small MySQL) using "Orchestrator" at Booking.com ten years ago. I checked if it was still kicking before writing this and found that the GitHub repo was archived last year. The next Google hit I find is this article from three days ago:
https://www.percona.com/blog/orchestrator-for-managing-mysql...
Please do some additional research into the state of maintenance of that piece of tech before jumping on it. But it certainly did a lot of powerful things for us back in the day. The automatic promotion of followers was key to our deployment.
That, and patching MySQL in weird ways. I recall something about the filesystem layer being monkeyed with, because "who needs safe writes, it slows things down"
Hahaha... Not galera!
Well kinda. Galera looks like it's an amazing solution, and it can be for careful operators who read the docs, learn the new procedures and ensure that they're running workloads that fit well. It can eliminate the usual HA / replication / failover stuff. But it has the ability to act like a foot-machinegun.
Outside kubernetes where you don't have an kubernetes operator that can run the database cluster, spin up nodes and pods, manage volumes etc it's difficult to imagine how you might automate that infrastructure in addition to managing the database cluster, without building a lot of it yourself.
Percona MySQL (i.e. Galera), ProxySQL, keepalived, the flavour of orchestration that is most compatible with your production environment and team.
Make sure you up ulimit and systemd LimitNOFILE in the MySQL service config. Read docs closely, preferably bring on someone who's spent some time making mistakes in this area to help out, test diligently before putting into production, including load tests.
Never tried myself, but there is Vitess as well that should do what you ask - not sure about the limitations. https://vitess.io/
As it involves multiple steps they use candence-workflow to orchestrate it. You could use it in a non k8s environment. Or something like Prefect.io.
> The MySQL fleet at Uber consists of multiple clusters, each with numerous nodes.
This is written like unintentional comedy! I'm glad their nodes are so... numerous.
The nodes are numerous and important.
Please enjoy each one equally.
Funny to read the negativity in here, I had the same impression. Also scaling MySQL is not interesting in 2025, seems outdated