Re: [GENERAL] PostgreSQL Global Development Group

Kevin Brown wrote:
> 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.

I think it /is/ a significant factor, the point being that the MySQL company
has been quite activist in pressing MySQL as "the answer," to the point to
which there's a development strategy called "LAMP" (Linux + Apache + MySQL +
(Perl|Python|PHP)).

> 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).

... And the consistent marketing pressure that in essence claims:

- It's easier to use than any alternative;
- It's much faster than any other DBMS;
- It's plenty powerful and robust enough.

As near as I can tell, /none/ of these things are true outside of very
carefully selected application domains. But the claims have been presented
enough times that people actually believe them to be true.

> 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.

I would point to a third thing: Tools to support "hands-off administration."
My web hosting provider has a set of tools to let me administer various
aspects of my site complete with "pretty GUI" that covers:
- Configuring email accounts, including mailing lists, Spam Assassin, and
such;
- Configuring subdomains;
- Managing files/directories, doing backups;
- Apache configuration;
- Cron jobs;
- A couple of "shopping cart" systems;
- A "chat room system;"
- Last, but certainly not least, the ability to manage MySQL databases.

There is no "canned" equivalent for PostgreSQL, which means that ISPs that
don't have people with DBMS expertise will be inclined to prefer MySQL. It's
a better choice for them.

> 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.

That's probably pretty fair. I'm using the word "fair" advisedly, too.

If someone objects, saying that PostgreSQL docs /are/ good, keep in mind that
new users are not mandated to be "fair" about this. If they have trouble
finding what they were looking for, they couldn't care less that you think the
docs are pretty good: /they/ didn't find what /they/ were looking for, and
that's all they care about.

> > 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.

Indeed. People with modest data storage requirements that came in with /no/
comprehension of what a "relational" database is may find the limited
functionality of MySQL perfectly reasonable for their purposes.

And I'll pull in a quote I saw on comp.databases this week that I think is
quite fabulous:

-------------------------------------------------------------

>>if you mean by "ideal" that it runs on Unix and crashes all the time
>>and needs a bazillion DBA's to keep them running and you want to
>>constantly recover your database and your data files, then you can
>>have ideal.

> A little background on my original comment might be in order. I
> don't tend to use the term "ideal" myself, much. I was referring to
> a comment made fairly frequently in this forum, to the effect that
> "A commercial Relational Databse system has never been built." These
> people exclude Oracle, SQL Server, DB2, Informix, Interbase, yada
> yada, because all of them fail, in one way or another to live up to
> the "ideal" of a truly relational system. I have a hard time with such
> terminological rigidity, myself. One can say that all those products
> aren't perfect relational products, but one shouldn't, in my view, say
> that they "aren't even relational".

Why do you think that they are "relational" ? Do they operate on relations ? I
don't think so. If their primary business is not to operate on relations but
on bags of rows, calling them relational is misleading.

Just like ODBMS are often database construction kits or persistence libraries,
SQL DBMSes are a real DBMS (they do provide transactions, recovery,
concurrency control, some data integrity) + a *relational construction kit*.
Meaning that by a skillful use of SQL one can come somewhere close to a
relational database.

But the complexity is left on the user to shoulder, and it is very difficult
to stretch SQL so that you are still in the realm of relational model. And
guess what: most users don't and most users suffer as a consequence.

It's even worse than that : very often product documentation and books
sponsored by the vendors (Oracle press: anyone there ?) simply lie to the
users by defining relational model in the most ridiculous terms. Actually they
screwed up their products, they built a multi-billion dollars industry by
taking agressive shortcuts on the implementation side and transfering the
complexity to the user and now they try to lie and cheat by proclaiming their
version of "relational" (not long ago the auto industry maintained seat belts
and airbags were unnecessarily expensive and not needed).

Best regards,
Costin Cozianu
-------------------------------------------------------------

The interesting argument that Costin makes is that SQL databases are /not/
"relational databases," but rather that they are tools that can be used to
construct relational database systems.

PostgreSQL has enough decent constructs, what with mature implementations of
foreign keys, views, and constraints that it is fairly easy to build
relational systems using PostgreSQL. In contrast, the paucity of supportive
constructs in MySQL means that neither the database nor the resulting
applications are likely to be terribly "relational" in the senses intended by
Codd and Date.

> 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).

The unfortunate part is that those that outgrow MySQL are likely to have /two/
misconceptions:

1. That the only /real/ reliability improvement will come in moving to
something like Oracle;

2. That PostgreSQL will be a huge step backwards into performance problems
because it is "so much slower."

That these are misconceptions does not prevent people from believing them.
(The third deceptive misconception I see is that MySQL is somehow "more
standard" than some of its competitors.)

> > 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.

I think it would be a Bad Thing if making PostgreSQL support Windows better
were to compromise how well it works on Unix, but I haven't seen evidence of
anyone actually proposing patches that would have that result.

> > 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!

You can't sell into the "ISP appliance market" until there's something as
ubiquitous as "PHPMyAdmin" for PostgreSQL. And note that the "ISP appliance
market" only cares about this in a very indirect way. They don't actually use
the database; their /customers/ do. And their customers are likely to be
fairly unsophisticated souls who will use whatever database is given to them.

> 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.

There are Oracle markets /not/ worth going after, at this point. You /don't/
go after the "ERP" markets or the data center markets where license budgets
are in millions of dollars, and where it's going to be tough to take
PostgreSQL seriously when Oracle is entirely prepared to send in a group of 10
technical marketing people to swamp the customer with marketing information.

What /is/ worth going after is the "small server" market, for departmental
applications. It's not "big bucks;" in the Oracle realm, it might lead to a
licensing fee of $20K. For $20K, they aren't going to send in a swarm of
marketers to fight for the account.

> 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.

Indeed.

It is almost a "necessary defense" to counter the deceptive claims that are
made. If nobody says anything, people may actually /believe/ that PostgreSQL
is vastly slower.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://cbbrowne.com/info/nonrdbms.html
"Power tends to corrupt and absolute power corrupts absolutely."
-- First Baron Acton, 1834 - 1902