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...
https://mariadb.com/kb/en/incompatibilities-and-feature-diff...
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.
Regardless, where possible, I use non-relational. When relational is required, I use Postgres.
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.
https://orangematter.solarwinds.com/2015/02/24/schemaless-da...
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.
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?
Source: 80% of global data will be unstructured by 2025 [citing IDC] https://www.analyticsinsight.net/the-future-of-data-revoluti...
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.
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.
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)
(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.)
It let lazy "coders" churn out simple brochure sites without having to think.