PostgreSQL 8.3 is out
Posted by David N. Welton Mon, 04 Feb 2008 15:00:00 GMT
http://www.postgresql.org/about/news.918
I've always preferred PostgreSQL to Mysql. I think the "worse is better" compromise is ok in some cases, but it's scary to see money being handled in transactionless MyISAM tables that are so widely used; I've done work for a number of places that had that kind of setup, and extrapolating from that, it's got to be very, very common indeed. I guess they heard it was "faster"... but I've always likened that kind of faster to the kind of faster you get by riding a bicycle with no brakes down a hill. Mysql's made lots of improvements over the past few years and is beginning to approach the robustness that Postgres has always had, but I'm going to stick with Postgres, and I'm glad to see they keep churning out cool new things, using the same sort of community open source approach that works so well at the Apache Software Foundation.
Why don't you compare it to InnoDB instead of MyISAM?
Olaf, like I said, a lot of improvements have been made in Mysql, and InnoDB is beginning to be comparable to what PostgreSQL has always done. The fact is though, that there are a ton of people out there running Mysql because it was "faster", because people were doing MyISAM comparisons. It's not ultimately Mysql's fault - except that it is, because its advocates used to wave away those "databasey" features as not really necessary and focus on the speed.
Just to be clear, these days either one is a good database in skilled hands, just that I have always preferred the safety-first attitude of PostgreSQL and have therefore continued to use it.
I can't disagree. There are tons of apps that don't need transactions.
I think where ever you feel comfortable in using any kind of software just continue using it. No matter how old it be as long as it's useful and comfortable.
True. Faster does not really mean better or more accurate really. I have tried mysql, nothing special about it really.
It's great that you like PostgreSQL that much. But why the MySQL "bashing"? It's true that a lot of places use transactionless SQL for applications that really should use transactions. However, I've seen this on both MySQL and PostgreSQL servers. I've also seen over-use of transactions (why do I need an explicit transaction around one single-table insert statement?) though. The choice of the RDBMS has more to it than the question of wether the RDBMS supports transactions on every database (or table) and the question of wether an application is secure depends more on the programmer of the application than on the RDBMS used. But yes, MySQL (3?) used not to support transactions at all, but that was years (and years) ago.
I don't really bash Mysql. I said:
It's scary to see money handled without transactions.
Mysql's brand of faster was not very safe (and still isn't, in MyISAM, which is the default). That's not 'bashing', it's a fact.
I picked on the Mysql advocates who have changed their tune as the database's features have changed.
Sven: you need to execute a single-table insert statement in a transaction because otherwise you won't be sure if you inserted just half of the rows intended, or none, or all.
In PostgreSQL every query is executed in a transaction, which gives you the warm and fuzzy feeling that when a query finishes successfully your data is as safe as can be. You can't do anything 'outside' of a transaction, and that's precisely what's good for you.
Of course there are situations in which you could care more for the speed that for the consistency, but I think they're very rare. MySQL's good up until your first HDD failure.