It was my impression that many distros alias mariadb as mysql because it's the capital-f Free version so when you install the default distro mysql you are actually installing mariadb.
I think this was more common years ago. MySQL and MariaDB have diverged more in the years since which means that people want to know which they're installing. For example, RedHat Enterprise Linux used MariaDB as the default in RHEL 7, but RHEL8 splits them back out.
While they're still quite similar and many of the differences might not be something that you hit, there are enough differences that it should be explicit.
This was really surprising. Back when RHEL 7 launched, it really looked like MariaDB was going to take over from MySQL. It doesn't look that way anymore. I suspect the reason is that Maria diverged too much, and people didn't want the risk of using something that they couldn't migrate away from.
Regardless, where possible, I use non-relational. When relational is required, I use Postgres.
Simpler, more flexible data model along with speed / storage efficiency (you’re not updating many indexes so writes are much simpler). Your transaction layer data model should be as flat as possible; enrich with relational data in your analytics systems and data warehouses to optimize query speed.
Beware however that this flexibility and initial ease is more often than not a slippery slope into chaos.
This article put it really well in my opionion: There are no schemaless databases, just the ones with an explicit schema and the ones with their schema defined in a couple hundred places in code.
One of them is slightly easier to start out with, the other to evolve, maintain and communicate (double serving as self-documentation) across multiple engineers.
The Internet is usually not presented to you in real-time in 3rd normalized form. There are times when you can control the data sources, but many times you will be presented with data in real time, and you cannot spend the time to normalize everything.
A lot depends on the data you have, and the data you anticipate. If you have well-controlled data sources, sure, 3rd normalized form and tables with JOINs.
But sometimes you have to deal with the data you're handed. Denormalized and only, at best, semi-structured. Then it's time for NoSQL.
i.e., choose the right tool for the data you have and the queries you need. Don't try to force-fit the data to a tool just because you're used to it.
Analogy: use a hammer for a nail, and a screwdriver for screws.
80% of the many zetabtyes of data on the Internet will soon be unstructured. Of the remaining 20% of structured data, only a fraction of it would even qualify as relational.
Other structured data could be simple key-value stores, tabular row-and-column stores (single table, no joins), and even graph data models. Like, an Excel spreadsheet is "structured." But it's not a SQL RDBMS.
All of which are basically "NoSQL" though you can shove it in an RDBMS if you want. Just as you can slurp an Excel spreadsheet into a RDBMS. Still doesn't make Excel "relational" per se.
Can you cite a source that shows the opposite to be true?
I don't have $4,500 to throw at IDC right now, but their latest in 2021 shows that "structured" data, while still smaller than unstructured data in absolute volumes, is now growing faster than the unstructured data. Basically by tagging it with metadata. (I guess that gives a video "structure?") But this metadata management can be done by use of NoSQL, as is popular within IIoT spaces, or by streaming OOT video providers, not just by throwing all data into an ACID-compliant, locking and blocking transactional RDBMS.
> There are no schemaless databases, just the ones with an explicit schema and the ones with their schema defined in a couple hundred places in code
This is a false dichotomy - there are better ways of self-managing the schema than "couple hundred places in code." There are valid usecases where a schemaless db is the better option (e.g. when you're recording self-describing data. Or when there is an implicit, consistent structure to the data - but the engineers won't know it at development time. Or when you want to do a full-take of structured data including unknown fields without losing data that's not in your DDL without resorting to file blobs, requiring additional data management)
> schema defined in a couple hundred places in code
Blame the developer who spread data specs in many places, not the database.
The application should have a single interface to interact with the database, hiding the implementation. All data specs should do in a single place, inside this interface.
But search queries of everyone using either DB on a day-to-day, high level development basis will probably just search for mysql and get better results. This is definitely what drives this google trend
FreeBSD is odd: you install it with `pkg install mariadb-{server,client}` but you start it with `service MySQL-server start`.
(The package name is moderated by the FreeBSD ports team, but the port (MariaDB) installs its service and gives itself whatever service name it desires.)
Depends on your use case. PostgreSQL is better if you actually USE any of its more advanced features (e.g. PL/pgSQL, JSON support, etc). But if your data model is simple and your need for scale is high, then MySQL is FAR easier to cluster and scale. Especially if you're working with Percona or another MySQL variant.
Edit: in fact I think that if you search "default" on this page these are all the distros that do this. https://mariadb.com/kb/en/distributions-which-include-mariad...