I honestly find MySql much simpler to use, create replication architectures, fix problems and use in general.
And its not like you switch to Postgres and your indexes are 10x faster.
Postgres does seems to be marginally faster in some edge cases, but with it you have to learn a whole host of weird slash commands, the tooling just isn’t that great, and setup is unbelievably complicated compared to MySql and heavily heavily intertwined with the host os.
The real advantage Postgres had is some cool party tricks (like pivot functions, super handy for prepping data for Ml) but those being non ansi means you are flirting with disaster if they ever change or go away. Backups on MySql are also not a great affair… xtrabackup is marginally ok but requires some intense scripting. (Honestly I question the usefulness of backups anyway, I think slow replicas are probably the was to go).
It’s certainly not bad, but it’s also not like it isn’t without a myriad of rough spots.
"SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax near '' at line 21."
when line 21 is 175 characters long. also, the fact that anything other than InnoDB is barely real ACID. also, the stuck development and lack of support for json, uuid and many other things.
mysql being user-friendly (and especially beginner-friendly) is a massive hoax.
Just because I spent a few hours in the postgres parser guts lately:
Postgres doesn't quite have the span of the error, just a single location :). We can of course measure the length of the token at the error point, but that isn't quite the same, as the cause of the error does not have to be a single token.
postgres[122581][1]=# SELECT * FROM kdjfkdj;
ERROR: 42P01: relation "kdjfkdj" does not exist
LINE 1: SELECT * FROM kdjfkdj;
^
This is probably referring to "zero changes to your driver code" and not "zero changes to the SQL you send over this driver".
Translating between SQL dialects is notoriously hard and attempts to translate [1] are working in 95% of cases. But the last 5% would require 5x amount of work. That's because "SQL dialect" also includes weird edge cases of type inference of things like COALESCE(5, FALSE) and emulation of system catalogs (pg_catalog, information_schema).
Probably something like an "80% of applications can be supported with 20% of the MySQL-specialized flavor", which is probably closer to 90/10, and those 90% of applications account for 99.9% of MySQL installations.
Well there are other Pg extensions that port MySQL specific functions and PL/PSM. One may even be able to leverage rules to rewrite certain syntax differences like intervals. (I saw such a project for an effort to partially support TSQL.)
I agree with the skepticism behind your question. I’ve used both at different firms heavily over the years. I’ll believe it when I see it. What about MySQL’s local @ variables… is that supported in Postgres? I guess they do say they will support MySQL’s procedural language… is there a difference between that and MySQL stored procedure compatibility?
Seems like it gets ignored by "MySQL" when, originally, it was a dropin replacement since MySQL was Oracle owned.
reply