4 ms·

I think MySQL's success comes down to developer-friendliness. I find Postgres a bit tricky to setup. For example, I don't like how Postgres authentication is in

I think MySQL's success comes down to developer-friendliness. I find Postgres a bit tricky to setup. For example, I don't like how Postgres authentication is intertwined with Linux user accounts by default; it causes more problems than it solves; especially for open source projects. But anyway, it's nice to read an honest piece like this once in a while. Many software projects these days are terrible (to be quite frank) and it's not pleasant to work on such projects as a developer once you understand that it is sub-par and that it will probably remain sub-par because your company doesn't have the talent or right incentives to attract or foster such talent. If you work at Oracle, it's better to do so as a lawyer, not a technologist. Oracle lawyers are world class cronies. Oracle doesn't even need developers; the letters written by their lawyers can negate the shortcomings of any of their code. Why even bother writing complex code to solve a technical problem when the lawyer can solve the same problem with a few paragraphs of English legalese?

ttfkam 5y ago
Postgres auth is intertwined? I mean, yeah, to create the first database and set of users, the local user must be in the postgres group. But after that (or if you edit the pg_hba.conf file)? https://www.postgresql.org/docs/current/auth-pg-hba-conf.html https://www.postgresql.org/docs/current/auth-pg-hba-conf.htm... It uses the current OS user as the default user to connect with. What else would you default to? But you can (and 99% of the time should) specify the role you're connecting with, which is a purely database-controlled role, not an OS username. Honestly I never thought MySQL's method was clearer, but I acknowledge that's subjective. That said, MySQL's solution for a VERY long time in its history was simply to default to superuser/root within the database until you lock it down. "Simple" turned out to be a security nightmare for a lot of folks who didn't realize what was happening, which was almost all new users. But that's mostly moot for most folks now. Managed database instances in Azure, GCloud, AWS, DigitalOcean, et al is rapidly becoming the norm (if it isn't already). In those environments, the connectivity options are really hard to distinguish between Postgres and MySQL.

ttfkam 5y ago

Postgres auth is intertwined? I mean, yeah, to create the first database and set of users, the local user must be in the postgres group. But after that (or if you edit the pg_hba.conf file)? https://www.postgresql.org/docs/current/auth-pg-hba-conf.html https://www.postgresql.org/docs/current/auth-pg-hba-conf.htm... It uses the current OS user as the default user to connect with. What else would you default to? But you can (and 99% of the time should) specify the role you're connecting with, which is a purely database-controlled role, not an OS username. Honestly I never thought MySQL's method was clearer, but I acknowledge that's subjective. That said, MySQL's solution for a VERY long time in its history was simply to default to superuser/root within the database until you lock it down. "Simple" turned out to be a security nightmare for a lot of folks who didn't realize what was happening, which was almost all new users. But that's mostly moot for most folks now. Managed database instances in Azure, GCloud, AWS, DigitalOcean, et al is rapidly becoming the norm (if it isn't already). In those environments, the connectivity options are really hard to distinguish between Postgres and MySQL.