The most advanced MySQL raytracer on the market - https://news.ycombinator.com/item?id=21218144 - Oct 2019 (47 comments)

MySQL Raytracer - https://news.ycombinator.com/item?id=21199895 - Oct 2019 (2 comments)

That, and the history of doing things “wrong” for the sake of performance, and the community banging on about how those of us caring about the data were just being picky¹²³, from long before Oracle came along. myISAM was the default for far too long.

> MySQL 8 with MyRocks engine

For those concerned about Oracle, there is of course MariaDB which also supports MyRocks.

I'm not sure what the current state of play is, but for a while at least MySQL was slower moving than MariaDB, getting CTE support (in production ready releases) a couple of years later for example.

---

[1] just implement FKs in your own code!

[2] why is 2005-02-31 being sent to the database anyway, why should it check for valid dates?!

[3] … you postgres/sql-server/other people are just expecting things the application should deal with, look how fast this is at bulk inserts compared to your “properly”!

for those of us who are old enough to remember actual internet flame culture, this is an amazing late example.

And fast back then meant cheap. Hardware was more expensive than people. It’s reversed now, of course, and we want extra layers and thing to make developers more productive. But back in the MySQL heyday, that was not the case, and I for one am glad something like it was around.

That was always one of the arguements, but beyond toy projects or at least beyond a single simple app accessing the DB the application layer is not the best place for that to be implemented.

Maybe I'm anal, but there is a point where giving up correctness for performance feels far too icky to me.

Also those professing mysql to be the solution back then did so with an almost religious furvour that is always troubling, and if something else threatened their messiah such as sqlite beating it in some benchmark by their own terms, ooh there were hissy-fits and claims of witchcraft!

So, yeah, lots of emotion in that. I only made ad money when site was up, and thus could eat. Such a direct correlation can make you (well, me in this case) a weirdo.

I never talking anything else down so much as give praise to that which saved my bacon.

Cloudflare was another one of those things when DDOSes hit.

MariaDB has been a drop-in turn-key replacement for us in every case... the MySQL drivers even work with MariaDB as the backend.

Nearly everything (perhaps everything) MySQL does, MariaDB has or has had long before MySQL got around to it. Nearly all (perhaps all) commands work exactly the same, which means any support doc or query you might want to run can operate on both without issue. You can even get commercial support for MariaDB from several companies including the very organization that makes it.

Not to mention, most of the original MySQL team works on MariaDB.

So, other than the folks that don't know or don't care about the history... why would someone go out of their way to choose MySQL these days? Is this the "OpenOffice" effect perhaps?

    The JSON alias was added in MariaDB 10.2.7. This was done to make
    it possible to use JSON columns in statement based replication
    from MySQL to MariaDB and to make it possible for MariaDB to read
    mysqldumps from MySQL.

    JSON is an alias for LONGTEXT introduced for compatibility
    reasons with MySQL's JSON data type. MariaDB implements this
    as a LONGTEXT rather, as the JSON data type contradicts the 
    SQL standard, and MariaDB's benchmarks indicate that performance
    is at least equivalent.

    In order to ensure that a valid json document is inserted, the
    JSON_VALID function can be used as a CHECK constraint. This
    constraint is automatically included for types using the JSON
    alias from MariaDB 10.4.3.[1]

Perhaps it's to borrow some elements from data stores like MongoDB, but whilst keeping most of the system based on the typical table/relation principles.

I've actually seen JSON used in PostgreSQL and admittedly I found the approach to be pretty horrible in most cases, performance/functions/syntax regarding the datatype aside.

Yet, I can't say that there aren't valid use cases for something like that, even if generally I'd advise against storing data that you actually want to query in a relational DB inside of JSON. Perhaps that's just because I believe that it'd increase complexity unnecessarily in most cases.

Saves a lot of time data modeling and managing schemas for that kind of non critical data.

I find it really useful to utilize normal relational db things for 98% of your table and then have a column or two where you can store json objects and run queries for deep nested values equals x and things like json contains such and such value, etc.

(It was reposted in April 2022 too - https://news.ycombinator.com/item?id=31167205 - but didn't get significant attention. That's the other variable.)