Re: POSTGRESQL Newbie

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(at)crankycanuck(dot)ca