I don't know why this comment is downvoted so much. Every company I've worked for uses MySQL (or a MySQL fork, eg. MariaDB or Percona). I've never seen an insta

I don't know why this comment is downvoted so much. Every company I've worked for uses MySQL (or a MySQL fork, eg. MariaDB or Percona). I've never seen an installation of Postgres used in production at any company I've worked for. I've been waiting for a decade to start using it, but there have always been three issues that made Postgres an unacceptable choice for my coworkers and me, at every single company I've worked for: 1. The lack of built-in replication, requiring third-party plugins based on slow triggers, etc. Postgres finally added, after many years, off-the-shelf replication, resolving this concern. 2. No equivalent to MySQL's "utf8mb4_unicode_ci" or "utf8mb4_unicode_520_ci". Postgres finally added, after many years, the "und-x-icu" collation, resolving this concern. 3. Lack of a multi-threaded model, meaning every new client connection forks a new child process, utterly decimating performance and scaling. Expecting users to throw a connection pool/proxy server in front of every Postgres installation to work around that bottleneck is unacceptable; a proper multi-threaded model needs to be provided off-the-shelf. The developers continue to fight back on this issue, and the fact is they are wrong. If and when that final point is resolved, I might finally be able to put together a proposal showing all of the benefits and features present in Postgres compared to MySQL; and with those above three points all resolved, I might actually be able to gain traction and support with the other senior developers, and win a plea to management.