Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group - Mailing list pgsql-advocacy
From | Kevin Brown |
---|---|
Subject | Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group |
Date | |
Msg-id | 20021216071549.GB9362@filer Whole thread Raw |
List | pgsql-advocacy |
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
pgsql-advocacy by date: