first off, how is it that there are so many of these? mind boggling

second, there's really only one correct answer here, i'll have a go at anyone who thinks otherwise

hint: the choices continue after scrolling beyond this picture for ages, but there is still only one correct choice

coz no one wants to adapt their code nor stack anymore, so theres a solution for just about every weird combination of requirements. Ideally a few should've died by now and their "good" features absorbed into their successors, dunno why it aint happening

@fullstackclown You mean storing and querying CSV files?

Only one correct choice?! I get that you love MariaDB most. But PostgreSQL isn't a bad choice either.

@Oktokolo mariaDB, LOL

@azuredivay There are a million reasons that ain't happening. For one, each feature needs to store corresponding data structures to ensure adequate performance, and unless those can be shared among several existing features, adding a new feature will result in higher memory and storage use, as well as slower performance as more data will have to be loaded and updated. That's why databases rarely release features that require any kind of change to the underlying storage engine. Second, use cases where one needs all the features for all the data are extremely rare, 99% of the time you only need one particular feature for a small subset of the data and having a specialised database for it gives a much better performance than using the same feature provided by a "general purpose" database. Adding new features to the database also makes it exponentially harder to make any kind of optimisations to the underlying engine, and the cost of maintaining something most users don't need, ...

@hitko ofc, i wudnt expect a 1-stop-shop DB to exist beyond a hobby project coz performance implications, BUT usually the industry standards converge around this time

Many would by now die out coz it wouldnt work with other tech thats aligned to a different standard

but in hindsight I guess since Data is one of the lowest/primary layers, it in itself is a bedrock of standard

And unlike say networking, not everyone needs to be on the same standard so as long as it's wrapped in a common exposed API, no one knows nor cares what happens underneath

but still, a weird sight still, im glad the options exist but definitely an anamoly compared to majority of things in tech

@azuredivay I'm not talking large-scale features, everything I said applies even if you were just trying to converge a few features among the main SQL dialects. A feature works well in one dialect because the underlying server and storage engine provide fast access to the relevant data; it won't work any good if added to a different SQL dialect because other storage engines don't store data the same way.

If you're doing lots of IO, you want a SQL database with the lowest possible read and write latencies. If you're doing lots of JOINs, you want a database optimised for that. You don't want some kind of "industry standard" SQL syntax or features, you want an SQL database optimised for your kind of workload. And you're not giving direct access to your database to any third parties, so fuck "industry standards", use whatever works best.

Which is exactly what people do.

Most of these database have entirely different feature sets and entirely different applicable work scenarios.

@fullstackclown i know at least 3/4 of those in the image...

Should I get the mud pool ready for some sexy wrestling over database engines and applications?

Come on, I know you don't want to, but I really could use some sexy time.

XD

@hitko i get that, but im not talking about Postgres should die over MySql, i club them together since in the end it's still SQL

My point was the various "save ur POJOs as JSON in this new DB"

"all our DB's content is a dictionary" kinda things

they have them as their primary freatures, and numerous such differing "primary features" exist, which normally cease to exist overtime barring a consolidated few

@Oktokolo Agreed, Postgres is quite nice.
MongoDB has their usecase, MariaDB has their usecase, NoSQL or whatever else there is, have their use case too.

Specifically Postgres i remember working with, when i was implementing some GIS System, using spacial data; was actually kinda fun.

I call that bloat! It only slows down the system and requires my time, which i don't have.

@galena stored in flat files?

realtime? check

hooks? check

row level security? check

functions? check

spatial functions? check

etc etc etc