PostgreSQL 9.0 Final Release Available Now(postgresql.org)
postgresql.org
PostgreSQL 9.0 Final Release Available Now
http://www.postgresql.org/about/news.1235
5 comments
Historically, MySQL has focused on ease of use, speed out-of-the-box, and aimed to be a lightweight, "personal" database (hence the "My"). This fast & light focus meant that certain "BigDB" features (triggers, transactions, ...) fell by the wayside.
On the other hand, PostgreSQL has historically focused on correctness and full support for advanced database features, looking to supplant Oracle and SQLServer. This meant that speed and ease of use sometimes suffered.
Today, though, both databases have mostly caught up -- MySQL has implemented most of the big ticket features that PostgreSQL had for years, and PostgreSQL (especially with the 9.0 release) has gotten far easier to use and tune, and is now as fast (or faster) than MySQL on most workloads.
The heritage still shows, at times: MySQL, even in "strict" mode, still suffers from annoying bugs and mis-interpretations of SQL features. PostgreSQL is still slow out of the box, often needing to be carefully tuned for the best performance.
Disclaimer: major PostgreSQL user and fan here. I've tried to give as objective an answer as I can.
On the other hand, PostgreSQL has historically focused on correctness and full support for advanced database features, looking to supplant Oracle and SQLServer. This meant that speed and ease of use sometimes suffered.
Today, though, both databases have mostly caught up -- MySQL has implemented most of the big ticket features that PostgreSQL had for years, and PostgreSQL (especially with the 9.0 release) has gotten far easier to use and tune, and is now as fast (or faster) than MySQL on most workloads.
The heritage still shows, at times: MySQL, even in "strict" mode, still suffers from annoying bugs and mis-interpretations of SQL features. PostgreSQL is still slow out of the box, often needing to be carefully tuned for the best performance.
Disclaimer: major PostgreSQL user and fan here. I've tried to give as objective an answer as I can.
It's more subtle than that. The MySQL people never really understood relational databases or the way they were used. Back in the 90s, their documentation was full of explanations about why you didn't need foreign keys (too slow) or transactions (do it in your application if you need it) etc etc etc. They "grew up" a bit as the years went by and grudgingly added a few of these features in as an afterthought.
But if you need a single-user database there's SQLite and if you need a free serious RDBMS there's Postgres. There's really no ecological niche for MySQL. It only hangs on because sites like Slashdot use it (and if you have thousands of reads for every write, and do only very simple queries, it is adequate).
But if you need a single-user database there's SQLite and if you need a free serious RDBMS there's Postgres. There's really no ecological niche for MySQL. It only hangs on because sites like Slashdot use it (and if you have thousands of reads for every write, and do only very simple queries, it is adequate).
Like I said, I'm a big PostgreSQL fan. However, I really don't think you're giving the MySQL developers enough credit here. Smart people -- and I maintain that the MySQL developers are a whole hell of a lot smarter than you or I -- can have differing opinions about trade-offs, and speed-vs-correctness is one of the oldest.
Proper implementations of foreign keys are transactions are slower, and many applications really don't need those features. Like you, I disagree with the choice to value speed over correctness, but unlike you I don't see it as an indication that the MySQL developers were idiots or immature.
Or, to look at it another way: if MySQL's such a load of crap, how'd it ever get so popular? It's not for a lack of alternatives. It's because MySQL offered a feature -- speed and ease of use -- that simply wasn't available elsewhere.
Proper implementations of foreign keys are transactions are slower, and many applications really don't need those features. Like you, I disagree with the choice to value speed over correctness, but unlike you I don't see it as an indication that the MySQL developers were idiots or immature.
Or, to look at it another way: if MySQL's such a load of crap, how'd it ever get so popular? It's not for a lack of alternatives. It's because MySQL offered a feature -- speed and ease of use -- that simply wasn't available elsewhere.
> Or, to look at it another way: if MySQL's such a load of crap, how'd it ever get so popular?
Justin Bieber.
Justin Bieber.
Even worse, IE6. The fact that it initially offered crappy implementations of some features that users were looking for doesn't make it any less crappy.
This comparison is right in the sense what it gets wrong: the time and context.
IE6 is sure crappy by today's standards, but back in 2001 it was the best browser you could get: Netscape lost it since release of Netscape 4 which was the crap.
And hey, IE6 even got box model fixed! Too bad it had no competition and stagnated till Firefox appeared and started kicking IE's ass.
In similar vein a lot of "criticism" of MySQL is done by those not aware of the latest developments of this DB, different engines it supports and different modes it can work in. Well, at least "MySQL does not support transactions" cannot be heard anymore.
My was Monty's daughter's name. It's also why his next database is MariaDB, that's his other daughter's name. The My as in ownership and My as his daughters name was just a good coincidence.
No, My is Monty's own nickname.
Might be true, but the MySQL docs state that the 'My' comes from his daughter:
http://dev.mysql.com/doc/refman/5.5/en/history.html
http://dev.mysql.com/doc/refman/5.5/en/history.html
I prefer PostgreSQL. The fact that it doesn't have many of MySQL's limitations is a big plus. Just he ability to add a column on a large table without locking the thing for a huge amount of time would be great for us. PostgreSQL can also use multiple indexes which, again, is a serious plus. The error messages that PostgreSQL returns can be much more informative than MySQL. At times when you screw up a query instead of "this is impossible" or "you can't do that", you get something more akin to "this is impossible because of X". Again, this is just my impression. Basically, PostgreSQL feels more like an open source Oracle (a grown up database) than MySQL (which doesn't feel very Oracle-y).
Now the tools are MUCH less friendly, but if you come from an Oracle (or probably DB2) world you'll be used to it. While they require more cryptic commands, they do work very well.
There is the replication thing. When we picked PostgreSQL back up this year to play with for a new little system, we discovered that they took one of the formerly external replication systems and it has been put into the tree. This is a very good step, as the replication situation was a big problem for us. Before there were little third party things (based on triggers) that you could take your chances with, and there were paid replication solutions. Having one built in is quite nice.
Now the tools are MUCH less friendly, but if you come from an Oracle (or probably DB2) world you'll be used to it. While they require more cryptic commands, they do work very well.
There is the replication thing. When we picked PostgreSQL back up this year to play with for a new little system, we discovered that they took one of the formerly external replication systems and it has been put into the tree. This is a very good step, as the replication situation was a big problem for us. Before there were little third party things (based on triggers) that you could take your chances with, and there were paid replication solutions. Having one built in is quite nice.
PostgreSQL forces you to write proper queries. MySQL is designed to accommodate lousy practices, and all those implicit type conversions and non-standard syntax will come back to bite you as a big WTF.
Other reasons I like PostgreSQL: more data types (MySQL doesn't even have a boolean type), partial indexing (a godsend when you have large tables), ability to use multiple indexes when querying, full-text search and ACID are not mutually exclusive, and multiple procedural languages.
[edit] Oops, didn't mean to make this a reply.
Other reasons I like PostgreSQL: more data types (MySQL doesn't even have a boolean type), partial indexing (a godsend when you have large tables), ability to use multiple indexes when querying, full-text search and ACID are not mutually exclusive, and multiple procedural languages.
[edit] Oops, didn't mean to make this a reply.
This. I was appalled when I realized that MySQL will quietly seem to execute
select x from y group by z
Of all the flamewar subjects, I think that one is just about the most tried and true one.
I wasn't trying to start a flamewar! I'm just coding up my first major project and needed help deciding, specifically which one plays better with django.
If you're using Django, and all else being equal, I'd choose PostgreSQL. Nearly all of the core developers (myself included) use PostgreSQL, so Django tends to have better support and we tend to find (and fix) PostgreSQL-related bugs a little bit quicker.
That said, plenty Django sites use MySQL -- including some of the very biggest ones -- without issues. So you're really in good shape either way.
That said, plenty Django sites use MySQL -- including some of the very biggest ones -- without issues. So you're really in good shape either way.
[deleted]
[deleted]
Yesterday's thread discussing 9.0: http://news.ycombinator.com/item?id=1706030
Full release notes http://www.postgresql.org/docs/9.0/static/release-9-0
Why use hot-standby over streaming replication or visa-versa?
It's a free upgrade from warm standby, whereas SR requires a little more configuration. A good SR cluster also requires that log archiving (warm/hot standby) be set up in case the stream gets behind, otherwise you're at the mercy of whatever happens to be in the master's xlog.
Hot-Standby: Ability to query against what used to be Warm-Standby boxes which were for disaster recovery only.
Streaming Replication: sending log data over sockets instead of relying on shell commands to send logfiles over.
They work together to make for happy master-slave replication.
It's worth noting this is database server level. Hot-standby copies 100% of a PostgreSQL instance. If you want to replicate individual databases on a server or individual tables in a database, Longdiste, Bucardo or Slony are still the way to go.
They work together to make for happy master-slave replication.
It's worth noting this is database server level. Hot-standby copies 100% of a PostgreSQL instance. If you want to replicate individual databases on a server or individual tables in a database, Longdiste, Bucardo or Slony are still the way to go.
EDIT: Okay, must've touched a few nerves there. Sorry. Question was asked in earnest.