With this office hours we had a lot of questions about MySQL and PostgreSQL
and why you prefer Postgres to MySQL, why other people MySQL a lot of the time.
If you could answer some of those, it'd be great.
Yes, yes. We'll start with the first question, which is why I prefer Postgres over MySQL.
This is a two-part answer.
Back in 2005 when we started Reddit, I was basically where you are now,
which is just learning how web apps work.
I was trying to install all this stuff on my computer, and I was trying to install MySQL and Postgres,
and MySQL wouldn't compile on my Mac and Postgres would. >>That's a good reason.
I mean, actually to be fair, it says a lot about a project.
Like if it builds on my Mac it'll probably build just about anywhere,
because at the time OSX was still fairly new.
That's how we started with Postgres.
MySQL at the time was still very popular--far more popular than Postgres,
but it had a reputation for being a little lossy with data.
This may be the right word--a little inconsistent.
Postgres--the documentation was better, they would sacrifice functionality over stability
and consistency and adherence to kind of the SQL standard.
Some queries that we did on Reddit that kind of pushed the limits of these databases
ran much, much faster in Postgres than in MySQL, so I've just been loyal ever since.
These days feature-for-feature they're basically the same.
MySQL is not nearly so cavalier with your data
and a lot of people use MySQL.
At this point, whichever you prefer.
Maybe go back to whichever compiles easier on your computer is
a perfectly acceptable reason these days, I think.
We also had some questions about other types of databases,
why NoSQL databases were popular, why a lot of companies are moving to that.
You mentioned that Facebook uses MySQL, I believe,
and we had some questions about them using NoSQL as well.
Okay, sure. NoSQL is basically a reaction to the difficulties of developing with SQL databases.
One of the challenges of SQL databases is you have define your tables ahead of time.
You have to know your coms are going to be. You have to know what the type are.
When you're writing web software, one of the advantages of writing web software
is you don't have to think everything through in advance.
You can get something working. You can put it online. You can see how users react to it.
You can kind of iterate from there--add new features, take features away--whatever you want to do.
The challenge is when you have databases and a large amount of data,
you have to sometimes add a new column or add a new index or add a bunch of new datatypes.
When you have a database in production that has thousands or millions of users,
this can be really painful.
These NoSQL databases--generally, they try to solve that problem.
Another way to describe them would be schema-less databases.
The databases don't have a schema.
That is they don't have a formal description of columns and datatypes, and it's neat.
On Reddit, we kind of built our own kind of schema-less system on top of Postgres.
We actually do the same thing again at Hipmunk.
It's a nice way of working.
The challenge right now with a lot of these schema-less databases is they're not very good.
They're brand new technology. Databases are really hard.
They have stability problems. Documentation is lacking.
Not very many of them are used in the wild in production,
so you don't have good support and people to lean on and that sort of thing.
In my opinion it's still wise, especially when it comes to data,
especially if you care about your data, to stick with something that's proven, that works,
that you know how to scale.
Everybody has worked with Postgres and MySQL for a long time now,
so those things work very, very well.
Now, as for Facebook--I don't work at Facebook, so I'm not an authority on the subject--
but I know they use a lot of MySQL.
They've actually made a lot of improvements to MySQL.
They also wrote their own NoSQL system, called Cassandra,
which my understanding--although I don't know for sure--is they don't actually use anymore.
Reddit uses Cassandra, incidentally. They started using that after I left, however.
I can't say with a clear conscious that I condone that decision,
but apparently it's working for them in production.
Your mileage may vary. Personally, I'm happy with Postgres.
I know how to scale it these days, and you can get away with kind of schema-less
behaviors in Postgres by just storing one column that's like a big wad of JSON, for example.
That actually works really well, depending on what problems you're solving.
Anyway, that's a long answer to a simple question, but that's my opinion. >>Great.