

What's new in PostgreSQL 9.0 - a User's Perspective  - jsrn
http://wiki.postgresql.org/wiki/Illustrated_9_0

======
moe
This is a wonderful upgrade that might finally convince some users to leave
the mess that is MySQL behind.

It's been a long wait but replication is now finally as easy as it gets. And,
by design, it can not silently lose or corrupt data. Unlike a certain other
popular RDBMS.

~~~
rufugee
I honestly can't imagine why folks continue to use MySQL over PostreSQL. All
technical benefits of PostgreSQL aside, I can't help but wonder if it really
comes down to something silly, like MySQL being much easier to pronounce
properly.

For my part, I'm stoked about 9.0. It can't get here soon enough.

~~~
ComputerGuru
Very simple: a _lot_ of pre-packaged software doesn't use except for MySQL.

Well, to clarify, a lot of popular pre-packaged software is out there in PHP.
And PHP never had a good db abstraction layer + the entire style of the PHP
language lent itself to the direct use of queries in the code, and the direct
usage of the MySQL connectors.

When users want a forum, a wiki, a helpdesk, a blog, etc. and it's in PHP,
chances are it doesn't have a PostgreSQL backend. And if you have to have
MySQL, and MySQL works for everything (for some definition of the word
"works") while PostgreSQL doesn't... there's your answer.

The real reason is: PostgreSQL doesn't have any must-have apps that _only_ run
PGSQL (which is a good thing), and MySQL does (which is a bad thing) so MySQL
wins.

~~~
njharman
This is exactly why there are two DB's at my work.

\- Postgres for Django and custom Perl system.

\- MySql for all the 3rd party crap WP, forums, Redmine, couple craptistically
old Perl help ticket and project management systems.

~~~
jeltz
Just want to note that Redmine runs just fine with PostgreSQL.

We do the same at my work too, but we have less third party apps that require
MySQL.

------
pilif
another year, another release.

Thank you, everyone behind the development of PostgreSQL. I wouldn't be in my
life where I am now if it wasn't for the work you are constantly putting into
this wonderful project.

And when one thinks "now. this is it. it can't get any better now", you come
out with another high-quality release.

Thank you ever so much.

------
avar
I keep hoping that PostgreSQL will support an embedded version. SQLite only
gets you so far, and it'd be nice to be able to ship PostgreSQL statically
linked into your applications with zero-configuration at the user's end.

MySQL's working on this (<http://mysql.com/oem/>), but I've read that
PostgreSQL is way too tied to their multi-process network architecture for
this to be feasible. But I'd love to be shown to wrong on that.

~~~
rbranson
I don't think it'd be terribly infeasible from an architectural standpoint
because of the multi-process network architecture, but there are other things
to consider. The multi-process architecture is really in it's favor, as it
already uses IPC primitives (shared memory, semaphores) to share cache and
control access to shared resources. The biggest barrier (I think) would be the
file format. SQLite stores all of it's data in a single file (plus one
temporary file for the journal). PostgreSQL's on-disk format would have to be
heavily redesigned to support this, which I think is a huge advantage for
SQLite.

~~~
avar
Then again, there's no reason why an embedded database can't launch multiple
subprocesses, or talk to itself via a socket for that matter. The same goes
for the storage SQLite uses one file, but an embedded PostgreSQL allocating
one opaque directory would be fine.

The important part is that you'd be able to easily statically link to it and
handle permissions on a by-file basis, instead of PostgreSQL's current
permission model. For all intents and purposes it'd be a larger SQLite
replacement then.

------
rbranson
This is it. The final release that will put PostgreSQL ahead of MySQL in the
performance and scalability realm. They've already exceeded or are at par with
MySQL in single-box OLTP performance, now PostgreSQL can scale-out with read
slaves. Other than entrenchment, there's very little justifiability in using
any other RDBMS system (proprietary or open source) after 9.0 rolls out.

------
mrj
Postgres just keeps getting better. 8.4 was a fantastic release, too.

I don't know how they manage it, but every release adds features and becomes
_more_ stable. Pretty awesome job.

~~~
rdeleonp
And they also get faster with every release.

A very high quality product, indeed.

------
jkahn
I've been wanting to use PostgreSQL. Does anyone know any good GUI tools for
MacOS X for it?

~~~
simon_kun
pgAdmin3 + SQLEditor (<http://www.malcolmhardie.com/sqleditor/>)

~~~
jkahn
Ah, it looks like pgAdmin3 is what I was after. It's a bit fugly but it will
probably do.

------
spudlyo
Just once I'd like to have a discussion on HN about either MySQL or PostgreSQL
without having a long thread about why one is more popular/better than the
other. Not going to happen.

------
MarkBook
I know that cost and cross platform capabilities are big issues but for
someone using MS SQL server express (free if database size < 10 GB) in
windows, are there any advantages that PostgreSQL has?

------
simon_kun
datapoint: I've been using PostgreSQL (and it's GIS extension PostGIS) with
Rails for over a year now. Some minor issues along the way, but never ever
going back to MySQL.

------
beatlevic
Does this release add any features that would keep you from going for a NoSQL
solution? How does it for instance compare to MongoDB in terms of raw
performance and scalability? (Not mentioning of course the difference in
schema-less and relational design)

~~~
crad
I have found Apples to Apples (fsync off in PgSQL) and doing key/value store
in PgSQL, PgSQL performed on par with, or slightly faster than MongoDB, using
my admittedly not fully baked KVPBench app - <http://github.com/gmr/kvpbench>.

~~~
gxti
FUN FACT: (and you probably already know this but many do not): "fsync = off"
is postgresql-ese for "please destroy all my data". Don't do it. Ever. The 9.0
docs are finally improving the language here to indicate that _you must not
set fsync off if you value your job_.

Setting "synchronous_commit = off" nets you 99.9% of the performance
improvement without the possibility of corrupting your entire database.

~~~
crad
You might enjoy my fsync related photo:

<http://www.flickr.com/photos/gavinmroy/4638958958/>

And the presentation it came from:

<http://www.scribd.com/doc/31669670/PostgreSQL-and-NoSQL>

~~~
rdeleonp
Very cool presentation.

