Just listened to the podcast. One big reason to use Postgres over MySQL is that Postgres has way better support for GIS and spatial data. I just checked the MySQL 6.0 manual, and it still says that all the nice functions for comparing two geometries (crosses, intersects, contains, within, touches, overlaps) are implemented using minimum bounding rectangles (MBR).
For example, you can get these nice shapefiles that contain polygons for each zip code in the US. MySQL will tell you that points near the borders are inside multiple zip codes because it just slaps rectangles around those polygons for comparison and calls it good. Or say you wanted to figure out how many of the plane crash coordinates in your DB occurred within the Bermuda Triangle? MySQL's search area is going to be 50% wrong. Postgres, on the other hand, is implemented the right way and can return the right results.
Did I mention that to make these functions perform well, you need spatial indexes that are only available using the MyISAM engine?
I ran into this a few years ago when MySQL seemed to be selectively ignoring my polygons. Fortunately, there's some hope on the horizon. Sometime recently, work began on making these functions more precise (why does MySQL's tracker lack datestamps?):
So there is one specific instance where postgres has a feature that MySQL doesn't have. I guess if I'm going to make an app like FourSquare or something that has lots of Geo data, I'll use postgres. That still doesn't explain why anyone should choose something other than MySQL for a small website that doesn't need to scale large, and doesn't do anything but serve up some content, maybe some comments, and other simple things.
My only experience with databases are pointing my forum to the pre-installed mySQL databases that came with my server and using the Microsoft Database (forgot what it's called) when I took a Visual Basic class in High School.
If you don't need scaling or features, you can pretty much use whatever (R)DBMS you want. I'd probably use whatever my hosting service provides, or I'd install MySQL since I've installed it before. Path of least resistance.
SQLite is pretty awesome, but I feel like a file-based DB would be sub-optimal for a web site back end. Not that I've tried it.
It is a really big thing that's lacking in schools. I learned all of my DB skills using MySQL making websites, and then I had to use Postgres for an internship. The only database class they offered at my college was not only completely optional, but they used Access. *facepalm*
Comments
For example, you can get these nice shapefiles that contain polygons for each zip code in the US. MySQL will tell you that points near the borders are inside multiple zip codes because it just slaps rectangles around those polygons for comparison and calls it good. Or say you wanted to figure out how many of the plane crash coordinates in your DB occurred within the Bermuda Triangle? MySQL's search area is going to be 50% wrong. Postgres, on the other hand, is implemented the right way and can return the right results.
Did I mention that to make these functions perform well, you need spatial indexes that are only available using the MyISAM engine?
I ran into this a few years ago when MySQL seemed to be selectively ignoring my polygons. Fortunately, there's some hope on the horizon. Sometime recently, work began on making these functions more precise (why does MySQL's tracker lack datestamps?):
http://forge.mysql.com/wiki/GIS_Functions
And despite all that, I rather like working with MySQL.
http://www.osnews.com/story/23236/Why_Our_Civilization_s_Video_Art_and_Culture_is_Threatened_by_the_MPEG-LA
SQLite is pretty awesome, but I feel like a file-based DB would be sub-optimal for a web site back end. Not that I've tried it.
It is a really big thing that's lacking in schools. I learned all of my DB skills using MySQL making websites, and then I had to use Postgres for an internship. The only database class they offered at my college was not only completely optional, but they used Access. *facepalm*