3 ms·
> Why is that a problem? I feel like this will inevitably lead to some not-very-productive discussions, as it already seems to have started in some sibling com
by KronisLV 4y ago
> Why is that a problem?
I feel like this will inevitably lead to some not-very-productive discussions, as it already seems to have started in some sibling comments.
Personally, I have to admit that there's definitely a trend of looking more in the direction of PostgreSQL, which is a pretty great choice - it follows SQL standards pretty well, has adequate performance, advanced procedural language with support for custom types and even nice projects like PostGIS, which let you work with geospatial data (previewing which is even integrated in pgAdmin). In addition, it has support for JSON (though personally I find the syntax uncomfortable) and other plugins as well, whilst being able to scale both up and down pretty far.
That said, I still think that MySQL/MariaDB is a sensible choice for lots of use simpler use cases, where you don't necessarily need custom types and advanced in-database processing with procedural languages (which in my opinion can be risky to begin with, mostly due to challenges in regards to testing and debugging such logic, outside of cases where you need to process a large amount of data and sending it over the network would be disastrous).
MySQL/MariaDB has a simpler structure (databases and users, instead of databases, schemas and users), good performance, very good driver support, excellent tooling (in my opinion, MySQL Workbench is ahead of pgAdmin, especially reverse/forward engineering and the whole ER visualization functionality), passable resource usage (a bit more RAM at idle and under load than PostgreSQL in my experience, at least with default container setup which you may/may not want to alter) and a nice ecosystem around it - be it clustering solutions or integrations with almost any language that you might want to use.
Also, projects like TiDB are interesting to behold, even though personally I wouldn't want to give up foreign key support for dynamic clustering.
At the end of the day, I think that either is a better choice than being stuck with Oracle which just feels more cumbersome and isn't as easy to run wherever you need it, licensing being a concern all of the sudden (and Oracle XE not letting you use certain features either, such as dynamic indices, which you might want to test on your dev environment/locally). Also, the modelling functionality on SQL Developer leaves a lot to be desired.
Cannot really comment on the SQL Server offering, because haven't worked a lot with it.
For anyone who's on the fence about what RDBMS to use, just pick whatever looks interesting from the top 10-20 here, do some benchmarks, read what others have said and come to your own conclusions for any given project: https://db-engines.com/en/ranking https://db-engines.com/en/ranking
It's hard to go absolutely wrong nowadays with any of the popular technologies (that have proven that they can survive for a decade or longer and still receive updates), unless you really misinterpret what would be a reasonable fit for a given workload.