List of software that has free tiers for developers
free-for.dev
free-for.dev
Fact: the optimiser in an SQL engine is almost the quintessence of it. If you don't understand that then you don't understand that the potential cost of the declarative nature of SQL.
Fact: SQL optimisers are complex.
New fact: microsoft has pumped fantastic amounts of cash into MSSQL. Posgres just doesn't have those resources (and other resources, such as the late lamented Jim Gray).
Other fact. Postgres CTEs were an optimisation barrier until PG11 or PG12 (https://www.depesz.com/2019/02/19/waiting-for-postgresql-12-...). AFAIK MSSQL's CTEs have never been an optimisation barrier, and I've used them long enough to know. I'm also trying to understand the cost of MVCC, which PG uses but MSSQL now has as an option, to try and understand where that costs, because depending on the scenario, it will. PG does not have READ UNCOMMITTED.
Fact: The guy I quoted had used postgres on large data a while back and said it wasn't as good as MSSQL. He had experience, which is the bottom line. I also acknowledged this may have changed recently.
Other fact: I don't dislike postgres and recently have decided learn PG also, because, for very good reason, MSSQL has its problems (the ridiculous cost not being the only one).
Fact: If you just downvote me without explaining why, neither of us can learn anything.
Didn't downvote you but your first comment I found vacuous. "Possibly", "could pump", "I was informed...I've no experience of it".
Your second comment then asserts things which may very well be true, but would be more believable with some references.
The 2nd post is harder to justify in a way. Some of it comes from experience, and understanding the behaviour of a merge join vs a loop join for example, and how much slower the latter can be if applied wrongly, which points to why the optimiser is so vital.
Edit: there's also the cardinality estimation (which can so easily go wrong), the dynamic programming for joins and the combinatorial explosion when it comes to ordering/reordering of inner joins, heuristic costs of using indexes vs not, etc.
Some of it was hearsay, but I stated it as such. Anyway, point taken, and thanks again.
It just occurred to me that Rust might be a really good fit for user defined functions in MySQL. I would never want to write in C or C++ myself, but with a nice crate that abstracts away and/or provides most the structures you might need to pass back and forth, I would be much more confident that if I got it compiling in Rust that it probably wouldn't blow up my database.
I mean, I think that's one of the major benefits of using C# over C or C++. You're not likely to segfault or buffer overflow, etc.
That said, I bet just about every database supports something similar (and postgres' equivalent has already been provided by a sibling comment).
1: https://dev.mysql.com/doc/refman/5.5/en/create-function-udf....
2: https://www.percona.com/doc/percona-server/LATEST/management...
Most of them. SQL-like languages like Oracle's PL/SQL are preferred, not because of any security problems but simply because it's much easier, specially when working with data sets.
The express (free version) may work for you but it's diversely crippled.
Why would I ever lock business critical data up in a database so that I would be beholden to one company, when perfectly free databases exists, that are in some ways even better?
Although a bit limited at the moment as it doesn't support every app.