The clock's ticking for MySQL 8.0 as end of life looms

Users have six months to migrate from MySQL 8.0 if they are to stay on a supported version of the open source database, or face security and reliability risks. Percona, a provider of open source database support services and Database-as-a-Service (DBaaS), has warned that more than half its MySQL instances remain on MySQL 8.0, …

[Alan Brown]

Time to consider PgSQL

Again....

There's a lot that Postgres does which requires masses of jumping through hoops in MySQL - and MySQL quite simply doesn't scale, resulting in a lot of effort going into tuning once your installation starts growing (there's also the woeful lack of replication ability to consider)

MySQL is a good database and useful for what it does, but far too many people are using it well beyond its designed use cases. I spent years banging heads against management who wasted man-YEARS trying to "stick with what we know" instead of biting the bullet and taking the step to a "proper" database which does natively what they were forcing people to code externally

MySQL was great 30 years ago when I was using systems with a whole 8MB of ram, but the greater initial memory/cpu footprint of PgSQL hasn't been an issue for at least 20 years

[kmorwath]

Re: Time to consider PgSQL

Tell Wordpress, for example.

Moving from MySQL to Posgres is not that easy - there are many differences to take care of. Especially if you use a RDMBS as a database **server** (stored procedures, functions, triggers, etc.) and not a **datadump** (simple tables only).

[Charlie Clark]

Re: Time to consider PgSQL

I thought there were Postgres backends for Wordpress? Whatever, it's such a piece of crap itself that I wouldn't really care about the database backend. I have had to work with it often enough to know how simple the schema is and, if necessary, could write my own converter if pgloader isn't sufficient.

What I don't understand is why newer projects make the same mistakes: CMS are much better served by more capable RDBMS systems. Ran some small travel blogs this year using Ghost – it's quite nice and will run on sqlite (as will many things to be honest) – but wants to enforce MySQL for future versions.

[kmorwath]

Re: Time to consider PgSQL

It's not officially supported, AFAIK there are plugints to run it on Postgres, but then you're bound to the plugin support for newer versions. Whatever Wordpress is, it's still behind a lot of web servers, and that means there are also a lot of MySQL databases behind it - which cannot easily moved to Postgres.

My application in the past ten years have always been on Postgres (I have an Oracle background) - but some applications leave no choice to users.

[Charlie Clark]

Re: Time to consider PgSQL

A common problem with many PHP applications, including WordPress I think, is using direct calls to the specific database rather than a shared connection: not only does this lead to DB-specific calls throughout the code, it can lead to connection limits being hit. And this was the dominant, self-perpetuating pattern for a while. Coming from the Python world, which has a DB-API, it was always odd to see

mysql_execute…

call compared to

connection.execute

I haven't looked at the source for a very long time but I think it does now define the database in the settings and the rest is largely abstracted away. There is certainly nothing in the schema or the calls that requires MySQL – it was designed to run on the non-relational MyASM tables.

[FIA]

Re: Time to consider PgSQL

(there's also the woeful lack of replication ability to consider)

What do you mean lack of replication?

Has that stopped working in the years since I last used MySQL? It's been a good ten years now but you could do fairly standard stuff last time I looked,

I'd probably chose Postgres over it these days, but that's more the big red factor.

MySQL is a good database and useful for what it does, but far too many people are using it well beyond its designed use cases.

One of the main issues with MySQL was it's support of multiple database engines, and the default for many years being one that didn't support transactions, long past the time where hardware was more than capable of doing transactions and speed.

This did mean a lot of people thought it didn't support stuff like transactions, even though it's supported them since at least 2001 and has had a transactional engine as default since 2010.

I wouldn't use MyISAM in production for anything, but I wouldn't have done that 20 years ago either. Last time I looked InnoDB was decent.

[Charlie Clark]

Re: Time to consider PgSQL

The support for different database engines was part of the way that the company MySQL sought to commercially exploith GPL code.

Doesn't InnoDB still have global table locking?

[alcachofas]

Upgrade hell

I spent a good portion of my last year at my previous job pushing to get our (long since deprecated) 5.5 instances upgraded.

It never happened.

I’d bet they’re still a way off reaching 8, let alone moving on from it

[Nate Amsden]

Migrated to Maria 10

From Percona 5.x (multi master replication) seems like almost a decade ago for a bunch of apps(including two internally built e-commerce platforms), zero issues on anything that I can recall. MariaDB systems have been running Galera clustering (which itself has required some minor changes with some queries at times due to how clustering works, same queries run against standalone instances never an issue). Perhaps the apps are just super simple, not sure.

Was a happy Percona customer for a couple years at least then one year they jacked the prices up by something like 8-10X, so we cancelled at that point.

[OllieJones]

Yes, MariaDB and MySQL have differences, but CMSs don't exploit those differences

A large fraction of MySQL instances exist to support the various php / apache or nginx based CMSs (WordPress, drupal, Joomla!, that lot).

And those CMSs don't exploit any distinctive features of either MySQL or MariaDB, but rather work with both. So migration should not be a nightmare of rewrites.

[Dom 3]

Yebbut Wordpress doesn't use mysql as a database, it uses it as a filesystem. Consider if you will the wp_users table. You, I, or indeed anyone with a modicum of Clue would put a unique constraint on the username. Wordpress instead opts to enforce uniqueness programmatically. With the inevitable consequence of a race condition resulting in duplicates when the site is being spammed with an autoregistration bot.

[fx: checks customer website]

Yup, another duplicate has snuck in since last time I cleared them out.

I spose I should actually just set a unique constraint myself.