Re: What can we learn from MySQL? - Mailing list pgsql-hackers

On Thu, 2004-04-22 at 21:09, Bruce Momjian wrote:
> Questions I have are:
>     o  Are we marketing ourselves properly?


It is perhaps less a matter of marketing and more a matter of
word-of-mouth mind share.  I don't see much evidence of effective direct
marketing, but I've noticed a huge growth in mind share among the
technical crowd over the last few years, which appears to be an
outgrowth of technical reputation.


>     o  Are we focused enough on ease-of-use issues?


No, and I think this is THE biggest impediment to popularity.  The real
question should actually be "ease-of-use for who?".  I had little
difficulty adapting to Postgres because I have tons of database
experience and so I knew what I was looking for in the technical
documentation, which is quite good for an experienced person.  But I
have noticed that most people who have a much more limited experience
with RDBMS administration have a hard time getting started because the
use curve is pretty steep.  "Ease of use" isn't an issue for people like
me -- I find it very easy -- but is a significant hurdle for most
everyone else e.g. casual developers.

Some specific recommendations on this:

- Make a standard GUI admin tool a prominent part of the standard
Postgres distribution, something along the lines of pgAdmin.  I don't
use it, but a lot of other people need it.  For casual database
developers, this will greatly enhance apparent ease of use.

- Pick a procedural language (plpgsql would seem like the obvious
choice) and make it a standard part of a Postgres installation. A
standard procedural language should be an out-of-the-box feature that
"just works".  Standard connection drivers (JDBC, ODBC, etc) should also
be installed by default and visible to the user.  Doing a "standard"
installation of Postgres for most people requires collecting a half
dozen bits and pieces that would be installed by default or as
install-time options for many databases.

- Make it much easier for the relatively clueless to install options in
their database.  Having an official menu of popular add-on modules (e.g.
some of the contrib stuff), and an easy way to automagically enable
these capabilities, will serve to educate users that these features
exist and encourage their use. I find that most new Postgres users
aren't aware that any of these things exist outside of whatever was
included with a vanilla install.

- Expanded documentation and well-indexed how-tos, both for the database
itself and for building applications using the database, for people who
are clueless about the technical details of Postgres internals would be
helpful. The standard documentation tree is a bit too "reference-y" for
less experienced people, and makes certain contextual assumptions that I
find many less experienced trying to navigate it don't have.  There is a
gap in the documentation between "total n00b" and "experienced DBA" that
makes it hard to transition that gap.


Postgres actually has very good ease-of-use for experienced DBAs, which
is something that it definitely gets right.  And comparing a Postgres
installation to an Oracle installation is like night and day.  The
problem is that there is no easy bootstrap path for people who aren't so
experienced with database administration and maintenance in general.


>     o  How do we position ourselves against a database that some
>        say is "good enough" (MySQL), and another one that some
>        say is "too much"  (Oracle)


Postgres should be positioned as an effective alternative to Oracle, and
the focus should be on the "enterprise" database space. Postgres has
some significant leverage points in the enterprise database space, even
today, and as it becomes more feature-complete it will increasingly
become a compelling choice within this space.

Comparing Postgres to MySQL is a mistake IMO, as it leads people to
assume that they are roughly equivalent products.  I actually read a
very recent Gartner Group report comparing Postgres and MySQL a couple
months ago that basically said that Postgres and MySQL are equivalent
products, but MySQL is easier to use.  And their reasoning basically
cited the myriad of MySQL versus Postgres comparisons on the 'net.  The
suits who did the research had difficulty evaluating the technical
merits and so they based relative equivalence on the fact that they were
constantly compared to each other in the same light.


>From a marketing standpoint, I would focus all my effort on comparisons
to commercial enterprise DB engines like Oracle and ignore MySQL.  This
will define Postgres as a part of the enterprise market and remove it
from the same market space that MySQL occupies.  



>     o  Are our priorities too technically driven?


No.  The greatest strength of Postgres, marketing-wise, are technical
and is what drives its growth today. I think most of the ease-of-use
issues are in the packaging of the larger Postgres product and mid-level
developer documentation, both of which seem to be eminently solvable
problems.  I think improved default product packaging would remove 80%
of the impediment to more widespread adoption.

There is no *technical* reason things should be done this way and it
might even go against the sensibilities of many current users.  But it
would go a long way toward widening the audience.


j. andrew rogers