Re: [HACKERS] PostgreSQL Global Development Group

Devrim G?ND?Z wrote:
> I do NOT like hearing about MySQL in this (these) list(s).
>
> PostgreSQL is not in the same category with MySQL. MySQL is for
> *dummies*, not database admins. I do not even call it a database. I
> have never forgotten my data loss 2,5 years ago; when I used MySQL for
> just 2 months!!!

I think you're on to something here, but it's obscured by the way you
said it.

There's no question in my mind that PostgreSQL is superior in almost
every way to MySQL. For those of us who are technically minded, it
boggles the mind that people would choose MySQL over PostgreSQL. Yet
they do. And it's important to understand why.

Simply saying "MySQL has better marketing" isn't enough. It's too
simple an answer and obscures some issues that should probably be
addressed.

People use MySQL because it's very easy to set up, relatively easy to
maintain (when something doesn't go wrong, that is), is very well
documented and supported, and is initially adequate for the task they
have in mind (that the task may change significantly such that MySQL
is no longer adequate is something only those with experience will
consider).

PostgreSQL has come a long way and, with the exception of a few minor
things (the need to VACUUM, for instance. The current version makes
the VACUUM requirement almost a non-issue as regards performance and
availability, but it really should be something that the database
takes care of itself), is equivalent to MySQL in the above things
except for documentation and support.

MySQL's documentation is very, very good. My experience with it is
that it's possible, and relatively easy, to find information about
almost anything you might need to know.

PostgreSQL's documentation is good, but not quite as good as MySQL's.
It's not quite as complete. For instance, I didn't find any
documentation at all in the User's Guide or Administrator's Guide on
creating tables (if I missed it, then that might illustrate that the
documentation needs to be organized slightly differently). I did find
a little in the tutorial (about the amount that you'd want in a
tutorial), but to find out more I had to go to the SQL statement
reference (in my case I was looking for the means by which one could
create a constraint on a column during table creation time).

The reason this is important is that the documentation is *the* way
people are going to learn the database. If it's too sparse or too
disorganized, people who don't have a lot of time to spend searching
through the documentation for something may well decide that a
different product (such as MySQL) would suit their needs better.

The documentation for PostgreSQL improves all the time, largely in
response to comments such as this one, and that's a very good thing.
My purpose in bringing this up is to show you what PostgreSQL is up
against in terms of widespread adoption.

> If we want to "sell" PostgreSQL, we should talk about, maybe, Oracle.
> I have never took care of MySQL said. I just know that I'm running
> PostgreSQL since 2,5 years and I only stopped it "JUST" before upgrades
> of PostgreSQL. It's just *working*; which is unfamiliar to MySQL
> users.

The experience people have with MySQL varies a lot, and much of it has
to do with the load people put on it. If MySQL were consistently bad
and unreliable it would have a much smaller following (since it's not
in a monopoly position the way Microsoft is).

But you're mistaken if you believe that MySQL isn't competition for
PostgreSQL. It is, because it serves the same purpose: a means of
storing information in an easily retrievable way.

Selling potential MySQL users on PostgreSQL should be easier than
doing the same for Oracle users because potential MySQL users have at
least already decided that a free database is worthy of consideration.
As their needs grow beyond what MySQL offers, they'll look for a more
capable database engine. It's a target market that we'd be idiots to
ignore, and we do so at our peril (the more people out there using
MySQL, the fewer there are using PostgreSQL).

> I'm a Linux user. I'm happy that PostgreSQL does not have win32 version.
> If someone wants to use a real database server, then they should install
> Linux (or *bsd,etc). This is what Oracle offers,too. Native Windows
> support will cause some problems; such as some dummy windows users will
> begin using it. I do not believe that PostgreSQL needs native windowz
> support.

I hate to break it to you (assuming that I didn't misunderstand what
you said), but Oracle offers a native Windows port of their database
engine, and has done so for some time. It's *stupid* to ignore the
native Windows market. There are a lot of people who need a database
engine to store their data and who would benefit from a native Windows
implementation of PostgreSQL, but aren't interested in the additional
burden of setting up a Linux server because they lack the money, time,
or expertise.

> So, hackers (I'm not a hacker) should decide whether PostgreSQL should
> be used widely in real database apps, or it should be used even by dummy
> users?

What makes you think we can't meet the needs of both groups? The
capabilities of PostgreSQL are (with very few exceptions) a superset
of MySQL's, which means that wherever someone deploys a MySQL server,
they could probably have deployed a PostgreSQL server in its place.
It should be an easy sell: they get a database engine that is
significantly more capable than MySQL for the same low price!

Selling to the Oracle market is going to be harder. The capabilities
of Oracle are a superset of those of PostgreSQL. Shops which plan to
deploy a database server and who need the capabilities of PostgreSQL
at a minimum are going to look at Oracle for the same reason that
shops which at a minimum need the capabilities of MySQL would be smart
to look at PostgreSQL: their needs may grow over time and changing the
database mid-project is difficult and time-consuming. The difference
is that the prices of MySQL and PostgreSQL are the same, while the
prices of PostgreSQL and Oracle are vastly different.

That's not to say that going after the Oracle market shouldn't be done
(quite the opposite, provided it's done honestly), only that *not*
going after the MySQL market is folly.

--
Kevin Brown kevin(at)sysexperts(dot)com