MariaDB Version Compatibility Issue with ERPNext 15 on Ubuntu 24.04 LTS?

When attempting to install ERPNext 15 on Ubuntu 24.0.2 LTS, I encountered significant challenges with MariaDB version compatibility. Despite following recommended installation guides, Ubuntu’s package management system consistently defaults to MariaDB 10.11, which is not compatible with ERPNext’s requirements.

Does anyone know any workarounds for this?

I’m following this one by the way:

@sideroomghost we always encourage to use ubuntu 22 . it’s more stable and compatible with frappe . switching to ubuntu 22 will solve your issue , otherwise you will have a hard time fixing all packages versions , not only mariadb .

2 Likes

You can use MariaDB 10.11 and Python 3.12 without any problem. No need to care about GitHub - D-codE-Hub/-Frappe-ERPNext-Version-15--in-Ubuntu-24.04-LTS

2 Likes

The newer MariaDB versions are fine; you just have to review your my.cnf configurations.

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

[mysql]
default-character-set = utf8mb4

For example, I am currently using ERPNext V15 + MariaDB 11.2.2 in a production environment, and it works just fine. This is far beyond the suggested 10.6 version.

1 Like

Just out of curiosity, what tangible benefits are there to using the version you mention. I see that frappe is still on 10.6.

I think it is better to know if there is any version dependent development or configuration which I think there is not as the framework is even compatible with PostGre. If there is a solid drawback or functionality in error, better to report it as we have LTS24 systems on latest update mariadb without any problem running for ages.
If you feel the need to ask why, well, I’d like to stay on the cuttting adge.

I cannot cite any direct, tangible benefits.

I chose to install the MariaDB version I did because:

  1. It seemed unwise to install a brand-new database server, but then deliberately choose a version from nearly 4 years ago (April 2021). Instead, I’d like to take advantage of whatever improvements the MariaDB Team has made since then.

  2. In the past 8 years, I’ve experienced many performance problems and headaches with MariaDB. If I continued using 10.6, nothing would change. If I installed the latest stable, the situation would either: Improve, get Worse, or Stay the Same.

    The only way to find out was to try, and see.

Also, Frappe/ERPNext is not doing anything strange or special with MariaDB; just normal SQL requests and syntax. So I was not concerned at all with moving from 10.6 to 11.X. If queries and statements worked before, they would certainly work now on the newer version. The only thing you have to be mindful of are configuration changes, like the previously mentioned collations, unicode/UTF things.

And if I was wrong? Well, then I’d go fix whatever Python/SQL needed fixing. No problem.

(fyi, it turned out that things did -not- improve, so I’m giving up on MariaDB entirely, and switching to Postgres. but that’s a whole other story. MariaDB 11.2 is running equally well, compared to 10.6)

4 Likes

Since I can restore a site backup taken from a mariadb running site on a postgres site, I can live with it :slight_smile: Have you ever tried @brian_pond ?

1 Like

No, I have not: interesting! I’ve just been using pgloader.

(post deleted by author)

Brian, it’s been a hot minute. Just curious, you still living in Postgres?

Any major hiccups that prevented you/slowed you down during the transition?

Yes, still happily living in Postgres :elephant: . No major hiccups. Just hundreds of little things that needed fixing or adjusting.

I’d say the most -interesting- challenges were things like:

  • Case Sensitivity (Postgres columns are case sensitive by default, but there’s a way around that).
  • Datetimes can now have Time Zones, if you want them to.
  • Certain default behavior was unexpected (collation sorting, certain functions returning Fixed Width strings).

It’s taken a lot of work, but I overall I’m very pleased. Database backups are faster and smaller. SQL Replication works very well, and doesn’t constantly break. Performance is great. And in the few cases where I had to cancel a long-running query…Postgres actually cancelled when I asked it to. :relieved:

I haven’t had a chance to pursue some of its more advanced features (I have a ton of other higher-priority projects on my plate right now, unrelated to databases). But I’m looking forward to them!