cbbrowne@cbbrowne.com wrote:
> Kevin Brown wrote:
> > 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)).
Oh, I'll certainly not dispute that marketing has had a significant
effect, but I don't think it's the only reason for MySQL's success.
History has a lot to do with it, because it's through history that
momentum gets built up, as it has with MySQL.
> > 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.
I agree with you -- now. But the situation as it is now has not
always been. Consider where PostgreSQL was 4 years ago. I believe it
was at version 6 at that time, if I remember correctly. And as I
recall, many people had very significant issues with it in the key
areas of performance and reliability. Now, I didn't experience these
things firsthand because I wasn't using it at the time, but it is the
general impression I got when reading the accounts of people who
*were* using it.
MySQL at the time wasn't necessarily any more reliable, but it had one
thing going for it that PostgreSQL didn't: myisamchk. Even if the
database crashed, you stood a very good chance of being able to
recover your data without having to restore from backups. PostgreSQL
didn't have this at all: either you had to be a guru with the
PostgreSQL database format or you had to restore from backups. That
meant that *in practice* MySQL was easier to maintain, even it crashed
more often as PostgreSQL, because the amount of administrative effort
to deal with a MySQL crash was so much less.
> > 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.
This is true, but the only way to combat that is to get PostgreSQL
more widely deployed. Network effects such as that are common in the
computing world, so it doesn't come as much surprise that the most
popular database engine in the webhosting world is the best supported
one for that role.
It's only because of the relative popularity of MySQL that it has so
much support. The only way to grow PostgreSQL's popularity is to get
it deployed in situations where the tools available for it are
sufficient.
> > 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.
This is true, but the biggest problem is that the requirements of a
project often balloon over time, and the demands on the database
backend will also tend to increase. Because MySQL is rather limited
in its functionality, it doesn't take much until you'll be forced to
use a different database backend.
This is why I view PostgreSQL as a much wiser choice in almost all
cases where you need a database engine. Your needs will have to be
quite considerable before PostgreSQL's capabilities are no longer
enough.
> 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.
This is true, but what everyone fails to ask is whether or not any
particular customer really *cares* about that. The customer isn't
interested in whether or not an application is "relational", they care
whether or not the application does the job it's supposed to. How
"relational" it is is an implementation detail to them.
The reason that PostgreSQL wins over MySQL is not so much that it's
easier to build relational systems with it, but that it's easier to
build *reliable* systems with it. That building the system in a
relational way is one way to achieve that is, again, an implementation
detail.
> > 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."
This is because people lack familiarity with PostgreSQL. That's where
marketing PostgreSQL well comes in.
The performance misconception is the result of history. At one time
PostgreSQL *was* much slower than MySQL. People need to be informed
of the current state of affairs.
> 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.)
The third misconception happens because most people equate "standard"
with "popular". And in the real world, they're not entirely wrong to
do so, unfortunately.
> 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.
I agree, and I also believe that the maintainers would not accept a
patch that compromised the performance under Unix for the sake of
supporting Windows. And rightly so: such a patch would indicate that
the people doing the Windows port haven't solved the problem properly.
> You can't sell into the "ISP appliance market" until there's
> something as ubiquitous as "PHPMyAdmin" for PostgreSQL.
But there is: PHPPgAdmin (or whatever it's called these days. I seem
to remember that they changed the name of it). Unfortunately it's not
as well known, largely because PostgreSQL itself isn't as well known.
> 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.
And if that's *really* true, then providers will do just as well to
provide PostgreSQL as they would MySQL (since their customers will
just use whatever database they're given). So it's really a question
of selling the providers on it, which (as you mentioned earlier) is in
part a matter of giving them the tools they need to make managing a
PostgreSQL installation easy.
> 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.
This is why marketing PostgreSQL *honestly* is so important. If it
won't do the ERP job well, then it behooves those who are promoting it
to realize that and restrain themselves appropriately.
> 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.
And this is exactly one of the markets that MySQL is currently
targeting. Of course, MS-SQL is *also* targeting this market, with a
reasonable amount of success. PostgreSQL is a *perfect* fit for this
kind of operation, and it's one of the reasons that it really *is*
important to have a native Windows port.
> > 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.
The way you counter such deceptive claims is to provide proof that
those claims are wrong. Point them at the head-to-head comparison on
the PHPBuilder site. Prove to them that PostgreSQL is in the same
league (if not better) as MySQL in the performance arena. And for
deity's sake, show them how much *less* work they'd have to do under
PostgreSQL because of its referential integrity features. I really
think most people would be willing to sacrifice a small bit of speed
if it meant doing a whole lot less work.
Copied to the advocacy group because of the relevance.
--
Kevin Brown kevin@sysexperts.com
