I’ve just heard about Ghost 5 only supporting MySQL 8, for this decision to be made, I reckon some research was done which led to the conclusion that justifies the choice, right?
Can there be some more explanation on what specific findings of functionality that MySQL 8 offers, that isn’t available/compatible with MariaDB?
Reason I’m asking is, that we currently run about 7 Ghost websites, all connected to MariaDB 10.4 and are planning to upgrade to MariaDB 10.7.
But since we heard about Ghost 5 specifically supporting only MySQL 8, and 7 Ghost site’s it’s quite a large portion of the applications that we run, we’ll need to do some research on the other applications needs, such as do those other apps use specific functionalities that MariaDB has, over MySQL?
Therefor I’m asking here, what specific functionalities will Ghost 5 be using that MySQL 8 has.
This will make our decision making hopefully a little bit easier, and will possibly justify the needed changes we’ll need to do.
Ghost officially supports MySQL; nothing has changed here. The only change with V5 is the need for MySQL 8; notices were displayed each time you updated Ghost.
Although MariaDB is considered a drop-in alternative and has worked, the Ghost team has decided to support a single database product because supporting more is a big overhead for a small development team (this is explained in the V5 announcement.)
MariaDB may continue to work, but there’s no guarantee. Indeed a bug with knex recently caused problems with MariaDB.
Thanks for you’re quick reply @mjw I get the team’s point of making a specific choice on MySQL / MariaDB for their maintenance part and their perspective.
But to better understand what exactly made them make this choice, I’d like the more detailed information/explanation.
Without some more detailed information, I can interpreter it as " If we state we only support MySQL 8, we are on the safe side and can easily defer MariaDB cases ".
I’m not saying it’s like this, but I want to better understand it from a Dev-OPS perspective why this choice has been made and what justifies the choice, so if Staff members can tell more specifically what functions MySQL 8 has that Ghost 5 will be using, it will be better to make choices ourselves on:
Does staying with MariaDB cause losing ( specific? ) functionality in Ghost ( and if so which/what? )
Will migrating a whole server - also used by other apps - from MariaDB to MySQL8 work out? Research on our side is needed to determine if other application we run need/use specific MariaDB functionalities
Worst case: Needing to run 2 database servers ( MariaDB alongside MySQL8 ) to pin and separate the Ghost blogs to MySQL8 and leave the rest on MariaDB
Which creates extra maintenance overhead that I’d like to prevent.
I think it risks your production sites failing. That what enough to motivate me to switch from MariaDB 10 to MySQL 8.
MySQL 5 was released almost a decade ago, and is end of life next year. So, I think you’re reading too much into the changes albeit I imagine the Ghost team is leveraging features only available in 8 for Ghost V5.
The very reason Ghost only (officially) support MySQL.
I think it risks your production sites failing. That what enough to motivate me to switch from MariaDB 10 to MySQL 8.
I totally agree when our database server was only used for Ghost applications, but it isn’t.
Therefor blindly switching to MySQL(8) from MariaDB(10.4), can cause greater problems.
So far Ghost is the only application in our application portfolio/landscape that prefers MySQL(8).
The very reason Ghost only (officially) support MySQL.
Which is also the very reason I’ve created this post from a Operational point of view.
I want to prevent having to run 2 separate database servers:
MariaDB that we are using already for all applications except Ghost
MySQL for specifically Ghost ( 7 ghost sites )
I hope the Ghost team can elaborate into more detail here on what exactly Ghost V5 uses in MySQL(8) that MariaDB doesn’t have.
There’s also the point that MariaDB is open source, and MySQL is proprietary, which is less of a point though.
I don’t think anyone is suggesting this. Nonetheless, not switching, in some way, does risk the Ghost services you run on your server, and that won’t change since the Ghost team has made it clear they don’t test Ghost+MariaDB.
Maybe your best option is to have a dedicated server for Ghost?
This is incorrect. MySQL is free and open source. It happens that Oracle owns the IPR (after buying Sun Microsystems), but anyone, including MariaDB originally, can fork the source code.
Curious: have any of those other pieces of software looked to drop support for MySQL 5 or start leveraging MySQL-8 specific functionality?
Also consider, most of those other piece of software are aimed at a technical audience & live in different ecosystems (e.g. PHP) where database interoperability is more mature and/or has more people contributing fixes around it.
Until recently, MariaDB and MySQL were so similar that you could drop in MariaDB without concern. That has changed, MariaDB has diverged from MySQL and that’s a decision and a course being set out by MariaDB, not by us.
MySQL5 is about to go EOL, so it’s a good time to get everyone to think about upgrading to MySQL8. With that comes some very beneficial features, of which the biggest and most obvious is JSON support.
Meanwhile, we are very aware that knex - the defacto tool in the Node.js ecosystem for handling database interoperability - isn’t getting enough traction or contributions. This means that minor divergences between MySQL and MariaDB, or even MySQL and SQLite3 are not handled correctly. Unfortunately as we’ve seen a lot recently, when there are bugs in knex, there’s an expectation from Ghost users that the Ghost team will fix them.
What we’ve done with Ghost 5 is draw a very clear line in the sand. We will continue to merge all upstream changes from knex, and there is nothing preventing you from using MariaDB, but we do not test against it, and we will not take responsibility for bugs that appear in knex when using MariaDB (or SQLite3 in production scenarios). We will also freely make use of MySQL8 only features as and when we need them.
If the community wants to keep MariaDB support going by contributing fixes and patches to knex so that MariaDB works or has graceful fallbacks in all these scenarios, that’s totally possible because Ghost and all the tools it depend on are OSS. I personally would love to see knex get more contributors.
Metabase: No, uses the MariaDB connector, see: https://www.metabase.com/docs/latest/administration-guide/databases/mysql.html#connecting-to-mysql-8-servers
Sendy: No
WikiJS: MySQL 5.7.8 is partially supported, see: https://docs.requarks.io/install/requirements/mysql5
Custom PHP: No, using MariaDB’s virtual column, but is in our own hands
Ghost: Yes, dropping MySQL 5, supports MySQL (v8+)
Mailtrain: Yes, dropping MySQL 5, supports MySQL (v8+) or MariaDB (v10+)
Mantis Bug Tracker: No, doesn’t support MySQL (v8+) and possibly MariaDB based on https://www.clevercomponents.com/tracker/view.php?id=1739 ( although we use MariaDB successfully )
SFTPGo: No
From a open source standpoint it’s a pitty that Ghost is choosing for MySQL proprietary, instead of MariaDB’s open source as Ghost should related to MariaDB’s philosophy based on:
MariaDB Server is one of the most popular database servers in the world. It’s made by the original developers of MySQL and guaranteed to stay open source. Notable users include Wikipedia, WordPress.com and Google.
MariaDB is developed as open source software and as a relational database it provides an SQL interface for accessing data. The latest versions of MariaDB also include GIS and JSON features.
But since the clear line is drawn, we’ve had to choose to set-up a separate MySQL (v8+) database server, next to the existing MariaDB server to facilitate Ghost exclusively.
By choosing for closed source MySQL (v8+), the Ghost philosophy doesn’t add up.
As mentioned before, these comments are fallacious, and unhelpful. MySQL is not proprietary, it is open-source, released under version 2 of the General Public License (GPL V2.)
I have been reading this exchange in view of other major deployments, where database selection is key, and MariaDB, with its truly open concept, growing support and user base, plus ever improving scalability are key.
MySQL is not closed source, but dual-licensed, so if you want to scale up, you have to pay. In this regard, all the above comments that are highly critical of the Ghost team’s choice to stick to MySQL are appropriate, future-proof and by no means fallacious!
Sorry, but with this move Ghost is, quite simply, off the table. Little wonder, it never made it into the FreeBSD ports!
First, I am not a member of the Ghost team. Second, stating that MySQL is non-OSS and closed source is a fallacy. MySQL Community Edition is open source. Period.
Because we also want that dependency too is not really a good reason to choose a database engine. That choice reveals priorities and limits on knowledge, in both my opinion and others’.
So, that’s why things are where they are. Ghost is still an awesome concept; the team just needs more support lower in the stack.
This link goes to a (possibly too-simplified) summary I wrote for this thread. My statement certainly isn’t evidence of what the dev team thinks. Please don’t cite it as evidence - you can scroll up in this thread and see what Hannah, Ghost’s CTO, actually said.
^^^ Yes, what @Cathy_Sarisky said, not complete evidence, just citing the conversation.
We digress, but some reasoning is healthy.
Ghost’s biggest asset is that it exists, and that far outweighs this SQL compatibility blip on the radar.
Knex.js is a yeah-boo. It is dependency stacking, but pure-SQL, which is also Vanilla. It seems to be part of the overall webapp/blog direction of “managing state”, which isn’t bad unless initial page load is too heavy, which Ghost is not in v5. So, good.
The decision seemed to have many factors which may be worth exploring on another topic.
I am still curious about that Knex.js bug with MariaDB from 2022 and whether it got reported or fixed. (GitHub/Knex)
It seems to be part of the overall webapp/blog direction of “managing state”, which isn’t bad unless initial page load is too heavy, which Ghost is not in v5. So, good.