On Wed, Mar 21, 2012 at 01:35:31PM +0200, Marti Raudsepp wrote: > Let's not forget that PostgreSQL sucked, too, back then. Well, for some values of "sucked". But I don't believe VACUUM was the main issue. In particular, > wrong, it would bog down all your hardware resources. MySQL lacked > many features, but it "just worked" without maintenance. this "just worked" was only true for some values of "worked". But the things it worked at were the things people wanted, whereas the things that Postgres worked at were things people didn't know they needed. I recall working with databases in the late 90s and early 2000s. When I started using Postgres, 7.0 wasn't out yet. The 6.x releases had some really serious problems -- back end crashes were by no means uncommon. What Postgres had going for it, however, was either features or stubs of features that, if you were used to real databases (or heck, even toys like Paradox or dbase), were things you couldn't do without. The problem was that you had to treat the database like old-line databases were treated: there was maintenance to do, and you had to plan for it. Also, you needed to think carefully about your schema in advance, because schema changes were difficult and tended to be disruptive. MySQL had exactly the opposite plan. The early MySQL releases were little more than a SQL gloss on flat files. The only reason to use MySQL was that you got a subset of SQL functionality. This was much easier to develop with than rolling your own back end support for your CGI or early PHP web pages. All you needed was to put some SQL calls in instead of figuring out how to write safely on the filesystem (from inside your web server, remember). And since the back end had very weak typing anyway, schema changes didn't need to happen that often (at the occasional expense of strange data, such as the famous date, '0000-00-00'). Anything that wasn't fast, cheap, and easy was a thing that didn't work and, quite likely, was listed in the manual as something stupid that no real programmer would ever even possibly need. Programmers with no experience whatever in database systems were perfectly prepared for messages like "foreign keys are stupid", "only morons use transactions", and "check data consistency in your application", because they were used to doing everything in the application anyway. (This disease is still with us, I am sad to say -- I cannot count the number of people I _still_ have to teach that round trips are evil and that two application servers that don't use transactions will inevitably get into a race and render the data corrupt, without a lot of extra work.) Moreover, because many people (I include myself) had grown up with systems that measured stability in hours and which randomly puked on the hard drive from time to time (thanks, Windows!), Linux seemed like a paragon of stability, and checking your database for corruption occasionally didn't seem like a strange thing to do. In short, MySQL offered the appearance of ease of use, which meant you didn't need a DBA or even, really, to read the manual. For most people it was good enough. It turned out that once you started trying to scale it, you really did need all those features that the MySQL 3.2.3 and earlier manuals said nobody would ever actually need; but by the time you found that out, you already had a sunk cost in your development so far, and MySQL's dialect of SQL was even stranger than Oracle's so it was hard to move away from MySQL. At least, that's my explanation for its popularity. As a disclaimer, however, I will note that explaining the popularity of products is almost always unsatisfying. Consumer behaviour, whatever a certain strain of economics says, is not obviously rationally maximizing. Best, A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
