Why doesn't Quora use PostgreSQL

This is a common mistake people make, I think. Just because an ecosystem is smaller does <i>not</i> mean it is inferior (or less practical). In fact, the opposite is routinely true.<p>Is it harder to find tutorials for PostgreSQL? Yeah, maybe. Is it harder to get high-quality advice and resources from subject matter experts? No; in fact, it's far easier. I have used PostgreSQL for many years and in all of them every question I've had has been answered quickly and properly by somebody in #postgres who knows way more about postgres and SQL than I'd ever even <i>want</i> to know.<p>And what about hires? When a million people "know" MySQL it takes a lot more effort to find somebody who actually <i>does</i>. There may be fewer contractors for PostgreSQL but they are practically by definition better than the average MySQL contractor.<p><i>unlike learning a programming language, with databases, the domain knowledge is harder to discover and more risky if you don't understand it</i><p>Exactly. So should you trust the ecosystem that relies on lazy, bandwagon developers for the majority of its market share, or the one that has been silently doing shit the right way for years? There may be a whole lot of really skilled MySQL admins out there (I guess there must be given how many huge sites go to extreme lengths to make MySQL work for them), but I can find you a handful of grossly overqualified PostgreSQL admins in no time. The same can't be said for the former.

Ok. Being borderline trollish here, but if I read this article, this means to me "yeah. we are using a technically inferior solution and thus risking data loss and increasing the workload on our developers because our HR department gets more resumes if we search for an in-house database specialist".<p>Postgres usually does its thing and does it well. You usually don't get weirdness that requires you to even hire a specialist. And if you do, the consultants around are great and actually understand the problem.<p>As other people here have said: If you find someone listing PostgreSQL experience on their resume, you know they have the experience. If you find somebody listing MySQL, you'd have to check whether they are just listing it because they have heard of it or whether they really understand the problem domain.<p>So. DB specialists are settled. What about developers? PostgreSQL and MySQL are close enough in what SQL constructs they support (no wonder - MySQL provides a subset of SQL anyways), so coming from MySQL to PostgreSQL usually is trivial and the few things that are unsupported unix_timestamp() for example, you can write wrappers for if you really need them.<p>Of course, developers will at first find it strange that they can't, for example insert a 200 characters string into a varchar(10) column, but even the most braindead developer sooner or later will understand that silently truncating data usually is a bad thing.<p>No. The arguments listed in that article are just fear of the unknown and total non-issues (in german, there's this saying: "Was der Bauer nicht kennt, das frisst er nicht" - ever so true).<p>I'm glad I can work with PostgreSQL day-in, day-out. I'm glad I migrated that huge application from MySQL to Postgres back in 2000. I'm glad I did not touch MySQL for serious stuff ever since then.<p>I understand if you need to use MySQL if you want to run some software that runs only on MySQL. But if you are writing your own application, there's just no reason not to got with the real RDBMS.<p>/rant.

A few bugs/limitations of Mysql not shared by Postgres. All AFAIK.<p>* Integer columns with null constraints will silently translate nulls to 0s, rather than throwing an error (as constraints in all other contexts do). Imagine a database which, on violation of a foreign key constraint, just silently picked the first row in the target table - it's just insane.<p>* Transactions can't roll back schema changes, so if you have a Rails migration which fails on the application of a unique index in the midst of other operations, too bad. Your DB is stuck in the no-mans-land between migrations.<p>* Constraints are anemic relative to postgres: no integer range or string length constraints, no whitelist, blacklist, regex match, &#38;c. &#38;c.<p>There are certainly others I've run into, but the above indicate to me that the Postgres developers are working with/delivering a better code-base.

Is quora flooding their own site with self-posed questions trying to get publicity and rankings? The only time I've ever heard of it is from the oxygen of publicity HN seems to give it.

It's interesting to see how PostgresSQL didn't get nowhere near the popularity of MySQL. I think a few major things contributed to this:<p>1) MySQL focused on performance first while PostgresSQL positioned themselves as "feature-complete."<p>Of course, that was years ago and in the meantime they became comparable in both aspects. MySQL+InnoDB is ACID compliant and Postgres matches the InnoDB performance.<p>Sure, Postgres might still have the upper hand in the variety of features but MySQL has MyISAM. If you don't need transactions you can get a significant performance boost over Postgres. Speed IS a feature and one could argue it's more important to many than all the nice extra things Postgres has.<p>2) MySQL was compatible with mSQL so they got a pretty good user base right from the start. mSQL later became obsolete.<p>3) Inertia. Even if Postgres would be net superior to MySQL (think feature complete but faster than MyISAM) it would still take a lot of time to catch up, if ever. There are tons of tools already developed for MySQL and a huge knowledge base around it. Just like C++, Windows, or any other big technology, there's a lot of inertia to it.

error 500. maybe its unrelated to them not using postgresql.

There are a number of companies that provide support for PostgreSQL. Enterprise DB is probably the most prominent of them. Kind of funny that they didn't have a good technical reason not to use PostgreSQL, just that the community was smaller.<p>Postgres 9, with streaming replication and easy to setup bullet proof read only slave replication will probably move momentum in the direction of PostgreSQL. The replication was always easier to setup on MySQL, which gave it an advantage.

Excellent lesson to other startups: When two or more products do what you need, choose the one you can more easily hire help for.<p>(not that there aren't a fair number of postgres experts, but there's no question there are far more competent mysql experts)

This article is an example of choosing easy option over the better option. From a startup's perspective, it's completely understandable. Thousands of cheap MySQL admins, or a few hundred expensive PostgreSQL admins?<p>As for the "nobody uses PostgreSQL" argument; Facebook and Twitter aren't an endorsement of MySQL because any Linux hosting provider out there will have MySQL installed BY DEFAULT. PostgreSQL would require you to upgrade to a more expensive account (for root access) and install it yourself. As a result, all the hobbyists learn on the free and always available MySQL when building "The Next Big Thing." Remember, Facebook was started in a college dorm room.

Those who commented in favor of postgres: What are some of the biggest deployments of postgres? Facebook has a gargantic deployment of MySQL and it just works. The author of the answer on Quora mentions reliable scalability as the most important factor for their MySQL choice on another answer here: <a href="http://bit.ly/dm6HtQ" rel="nofollow">http://bit.ly/dm6HtQ</a>. What is the biggest system that postgres is deployed in?

That's why database abstraction is so nice. If I ever get sick of MySQL - or say, decided I didn't want to use Postgres - it's not hard to switch!

there's one useful thing about postgresql:<p>specifically, interviewees that inform you you should be using postgresql can be immediately rejected.<p>"do you use mysql or postgresql?" "oh, mys-" "YOU SHOULD SWITCH TO POSTGRESQL!!"