I just launched a Windows-Apache-Postgres-Python/Django stack on EC2 using Elastic block for the postgres database storage. That install worked like a charm, and I'm running www.cuuute.com on it right now.
I had an urge to try MySQL as a database, and I found an installer bug that broke the installation and messed up my server. The installer died giving me a "MySQL can't install as a service" error, and then not allowing me to go forward. So, I did that a couple of times. I then realized that the installer had installed MySQL each time I ran the installer, but didn't complete it.
I Googled for an hour and couldn't find a resolution to the issue, just a bunch of forums= threads asking for help on the same problem for the past 9 months.
Postgres for the win. BTW EC2 + Elastic block rocks like Dokken for a WAPP setup.
I think there is a big difference between the two.
The FSF uses copyright assignment to ensure that open source code is not legally encumbered.
MySQL uses the copyright assignment so they can sell code contributed by open source developers in their commercial platform without compensating the authors.
That's not really true. They both do it so that they have the ability to relicense the code to their ends and defend any legal challenges against the code-base as a whole. If MySQL just wanted to be able to use the contributed code they could simply require that it be under a less restrictive license (BSD, MIT, etc.)
Yeah, that's a good point. Well, like I said, I am firmly in the Postgres camp in any case. I've never enjoyed discovering things about Mysql like the fact that even InnoDB doesn't allow you to modify the DB transactionally.
Meaning you can't change the schema transactionally. InnoDB handles data transactions ok, but I hadn't realized that it doesn't handle schema changes. It seems like I'm always discovering some little nasty about Mysql when I am forced to use it.
Wait, was there supposed to be some content in there? That post was basically flamebait. You can sum up everything useful in there with news that's already made the rounds, "MySQL founders left Sun."
My beef about MySQL used to be technical but in the last 3 - 4 years that has evaporated, and now it is purely about the license. I cannot understand why anybody uses a database for which the only official client side drivers are GPL, rather than (at least) LGPL. Unless you really truly intend that your own app will be licensed GPL and so will every other application / piece / component/ that ever needs to interact with your database in any way, it is a ball and chain around your neck which seems crazy to place there when there are other equally good alternatives.
At the moment, it's not even possible to download and install MySQL anymore.
I was setting up a Wordpress install a week ago, so I headed over to MySQL.org and hit the download link. They won't let you even download it without having your company "Reviewed" these days. So I filled out my info and was told I'd hear back when they were ready.
That was a week ago. No word back. I still can't even download it.
I could never understand anybody would use MySQL for anything business critical. Now it seems that nobody is allowed to use it for anything at all.
The article presents the problem as mostly organizational and not with the actual software. Maybe the parent comment was a little off topic, but it also serves to further illustrate the problem.
The parent commenter was familiar enough with the product to know he wanted to use it, but the project and its strategy is so disorganized that he walked away empty handed. Now he's unknowingly spreading misinformation to other people who may be deciding whether or not to use the product.
This is really a perfect example of what the article discussed. MySQL tries to present itself as an open source organization but does not function as such, resulting in confusion and frustration among contributors. The fact that consumers are also confused over what they can and can't do only goes to show that these mixed messages have permeated the entire organization.
This is an ooold problem, and I don't mean organizational, but people confusing the download link. I think I did it first at least 5 years ago. Still, the GP should be downmodded at least to a pale gray, maybe -2, and stay there. An honest mistake is still a mistake, and it's our job to mark it clearly as such.
As far as the project being disorganized, I'd much rather think this comes from the old days when men were men, documentations came in man pages and people were ashamed of not RTFM. I know I held my head down for at least a week after that.
I've been using MySQL since 1998, and am well aware that there is a commercial version as well as the open source one. It's the community version I was trying to download.
The fact that me, a guy who's downloaded and installed this software a dozen times in 11 years, got completely shut down trying to download it this time says a lot about the usability of that site these days.
i just went to mysql.org and within 3 clicks was at the download page. you probably saw the links to the commercial version and clicked on those instead.
however, why wouldn't you try to download it through whichever package management system your operating system uses? i'm sure whatever you're using already has pre-built packages that have been patched/tested for your specific platform.
Also, documentation is hard to find on the mysql.com site. If it weren't for google taking me directly to the page I need on a search for "mysql [searchterm]", I'm not sure how long it would have taken for me to find the doc I needed this morning on their site. It's as if they've decided to ditch the main community of their users. :)
--> Pick a Mirror --> New User --> Giant Form full of required fields.
That's the form I'm still waiting to hear back from, a week later.
(Looks like they have a "skip this" link buried down below it, but really, are we expected to scrutineer the page that carefully just to download their thing?)
I have tried to search for MySQL vs. PostgreSQL benchmarks and most of them date to 2007. Are there any recent benchmarks that compare these databases?
I personally use MySQL and I think it's an OK database (performance and installation wise) and I think it's a bit risky to jump on PostgreSQL when most others use MySQL (e.g. Flickr, Facebook, Yahoo, Google just to name a few).
Of note, Sun ironically performed a benchmark between PostgreSQL and Oracle. The results were that PostgreSQL performed very closely to Oracle under several scenarios.
Benchmarks between DBs are pretty rare because they are so difficult to control for. The configurations make a big difference. One set of benchmarks is here: http://tweakers.net/reviews/657/6 but thats in 2006. Also, MySQL has known fatal bugs in the production release so mysql isn't exactly a safe choice.
Postgres doesn't have native replication AFAIK - what are the state of the plugin projects that provide this functionality, and how do they rate against the MySQL clustering?
Feature wise, I don't think there are many things that MySQL can do that PostgreSQL can't given a proper configuration. The main difference is that PostgreSQL doesn't include things like clustering as part of the core distribution like MySQL. They are often released and maintained as third-party add-ons to the core platform.
For instance, PostgreSQL has a number of projects that facilitate clustering. Slony-I is a stable open source replication framework (http://www.slony.info/). PGCluster provides a multi-master replication facility (think Oracle RAC). PGpool allows front end load balancing of connections.
AFAIK, none of the add-on replication mechanisms you mentioned can guarantee total consistency across multiple database backends: OIDs are not replicated, and there are no hard guarantees against external modifications taking your databases out of sync.
As an alternative, you can use Point-In-Time-Recovery (PITR), also known as "log shipping", to transfer copies of your write-ahead log files from a master server to a warm standby. PITR allows you to have an exact replica of your master database, modulo whatever delay you incur in the log transfer itself.
For those who haven't aren't familiar with write-ahead logs, they function much like the logging in modern filesystems: changes are written there before being flushed to disk, so any incomplete transactions can be replayed from the logs if the server goes down unexpectedly.
Of course, the log-shipping method doesn't allow your secondary server to serve as a read-only replica as MySQL's built-in replication does. Largely for that reason, (depending on your workload and requirements, of course) MySQL may be a better choice. However, I've found Postgres PITR to be an excellent option for low to medium-traffic databases in those cases where I'm willing to trade the possibility of the loss of a few seconds' updates for guarantees that my DDL, object identities, and constraints will be maintained consistently between my replicas.
For those who are curious, the PostgreSQL docs online have a decent introduction into the use of write-ahead logs for replication and backups:
Given my experience with how often MySQL master/slave replication breaks, and how often tables corrupt themselves, I would argue that MySQL doesn't have native replication, either.
From what I have heard, the plugins work pretty well. Also, the postgres team has decided to integrate some replication into the core codebase so expect some change on that.
http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
Database-wise, they should be still considered recent. PostgreSQL features impressive scaling there.