> We are also now defaulting to MySQL for production blogs as a future-proofing measure.
Oh FFHS, must this scourge infect everything?
And there's no Docker image for 1.0 up yet.
Oh FFHS, must this scourge infect everything?
And there's no Docker image for 1.0 up yet.
I find this hard to fathom since SQLite is generally closer to Postgres than MySQL is to anything else:
> I wrote SQLite, and I trust Postgres to be more ANSI conformant. I used Postgres docs as reference when developing SQLite.
Looks like the Ghost team is welling to share an official Ghost Docker image after all :)
Trying to build this with Windows during the beta phase left me with plenty of issues as well. They do have a good Slack channel though & are active on GitHub, so kudos to them for always being responsive.
Hosting your own version has also always been a bit of a pain when wanting to use Docker on AWS or Azure. For example, you probably want to store your uploaded files in an S3 bucket or similar. That requires adding some node modules & doing minor configuration. I think it's safe to say Ghost would rather make it a bit painful to host this on your own.
If someone is looking to create the next Wordpress, Ghost is a great place to start. Just like Wordpress they started out with a focus on being the best CMS for blogs. They have a great platform but it is missing a lot of core features that are important to bloggers. If anyone is interested in doing this, I would be glad to chat.
The mentioned why they dropped it here: https://dev.ghost.org/dropping-support-for-postgresql/
> Without active community support, Postgres has always been, and always will be a second-class citizen. For that reason, we are dropping official Postgres support from Ghost core.
"Because it's easier to slap a system together on MySQL". Which, to be fair, it is but that's not a good thing when you're talking about data.
It's like Rails - it's easy to slap something up but once you start using it in anger, it requires all the handholding and effort.
The model it replaces/improves on is self-host on shared-hosting web hosts. That used to be php and mysql - I guess they kept mysql, even if nodejs doesn't lend itself to the same type of shared hosting as php does (in fact, neither does php, but that's a battle for another day).
Anyway, many hosting services will throw in a database instance on a more-or-less well-managed mysql cluster - at a minimum there might be some semi-regular backups of the database, with some automation for doing restores (and with more than a bit of luck, they'll keep snapshots, so that the sql injection that wiped your database haven't resulted in all-empty backups by the time you realize).
I don't think it makes much sense, but I doubt it is because "postgres is hard, mysql is easy".
After many years of security issues and its general inability to be a good database, I refuse to install it on any of my own boxes. If I need something heavyweight, I'll use Postgres; otherwise it'll be SQLite - both of which manage to be more secure and competent than MySQL.
Judging from shitloads of successful companies and projects running MySQL in production I'd argue the inability here is with the developer. Can you substantiate your claim or is your dissatisfaction just rooted in your inability to run a MySQL server?
There's several good alternatives - Postgres being free, MS SQL Server being a reasonable paid-for option, and there's Oracle and IBM's database systems at the high end.
One of the only reasons to develop a new project for MySQL (assuming your developers are at all capable of writing queries for Postgres, which is hopefully the case) is that you know your deployment environment is going to have MySQL. Which is probably the case here - LAMP is still a popular stack among PHP developers, so there's a very good chance that anyone wanting to deploy Ghost already has a MySQL server.
As a counterpoint, many successful companies run PHP in production but I don't think anyone would claim that means it's a good language.
(One example of where MySQL lack{s,ed}: Postgres with a functional index on a field handled the exact same query on the exact same data a couple of orders of magnitude faster than MySQL on the exact same box.)
not talking from experience though, never used it for anything remotely serious.
Also, big appeal to authority here, many successful companies do silly things with databases.