Re: Democracy and organisation : let's make a - Mailing list pgsql-hackers

> -----Original Message-----
> From: Josh Berkus [mailto:josh@agliodbs.com]
> Sent: Tuesday, June 25, 2002 10:49 AM
> To: Bruce Momjian
> Cc: Tom Lane; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Democracy and organisation : let's make a
>
> Bruce,
>
> > I think Oracle is our main competitor.  We seem to get more people
> > porting from Oracle than any other database, and our
> feature set matches
> > there's most closely.
>
> I disagree, and did as well when you were with Great Bridge.
>  No matter how
> Postgres core functionality compares with Oracle, they have
> nearly a decade
> of building tools, accessories, and extra whiz-bang features
> for their
> product.  Not to mention a serious reputation as the
> "ultimate database if
> you can afford it."
>
> As long as we target Oracle as our "competition", we will
> remain "the database
> to use if you can't afford Oracle, but to be replaced with
> Oracle as soon as
> you can."  Heck, look at DB2, which is toe-to-toe with Oracle
> for feature
> set, but is only really sold to companies who use IBM's other
> tools.  We're
> not in a position to challenge that reputation.
>
> On the other hand, we already outstrip MS SQL Server's
> feature set, as well as
> being more reliable, lower-maintainence, multi-platform, and
> cheaper.
> Frankly, the only thing that MS SQL has over us is
> easy-but-unreliable GUI
> admin tools (backup, user, and database management).
>
> Let's pick battles we can win.  We'll beat Oracle eventually
> -- but not in the
> next few years.

If you want to aim high, aim at DB/2.
;-)

DB/2 is the best database on the market in terms of its features.  It's
highly scalable, runs everywhere, and has an add-on for anything you can
imagine.  I absolutely love DB/2.  I suspect a market share study will
show that DB/2 is eating Oracle alive in the past couple years.

There is a benefit to setting your sights high.  Look at the features of
the really rich products.  Take the ones that are truly possible to
implement in a feasible time frame and add them to the project goals.
Eventually, you can have every feature of the most advanced DBMS systems
in that way.

I do have a suggestion as to strategic thinking on how to improve
PostgreSQL.  Instead of adding a huge array of features on the to-do
list, attack the weak points of the current product.  Here are the three
most important aspects of any DBMS system:
1.  Speed
2.  Reliability
3.  Security

Look at places in the current product where these can be improved.
Think about this for a minute --
If your product is faster, it will appeal to a large crowd for that
reason alone.
If your product is more reliable, it will appeal to a large crowd for
that reason alone.
If your product is more secure, it will appeal to a large crowd for that
reason alone.
None is less important than the others.  If any of the above 3 features
are seriously lacking, nobody will want to use the tool.

Bells and whistles are nice, but you still want the bicycle to go as
fast as possible while not breaking down and keeping the rider safe.

So my suggestion for project direction would be as follows:
2/3 effort on improving functionality of the core in the above three
areas.
1/3 effort on adding new features.

Now, I have had very little to contribute myself, and therefore my
suggestions carry no weight.  The opinions of the contributors are more
important than someone from the outside looking in.  But it is worth
mulling over at least.

There is one feature to PostgreSQL that does seem to be missing that is
found in all the commercial systems that I have worked with (and so I
would suggest adding it to the 'new features' list).  That is the
ability to perform stored procedures that return one or more row sets.
The PostgreSQL paradigm of a stored procedure seems to me to be really
limited to a function call.  Perhaps it is already being worked on.