GNU Info

(mysql.info)MySQL-PostgreSQL goals

---

Next: MySQL-PostgreSQL features Prev: Compare PostgreSQL Up: Compare PostgreSQL

---

Enter node , (file) or (file)node

MySQL and PostgreSQL development strategies
...........................................

When adding things to MySQL we take pride to do an optimal, definite
solution.  The code should be so good that we shouldn't have any need to
change it in the foreseeable future.  We also do not like to sacrifice
speed for features but instead will do our utmost to find a solution
that will give maximal throughput.  This means that development will
take a little longer, but the end result will be well worth this.  This
kind of development is only possible because all server code are
checked by one of a few (currently two) persons before it's included in
the MySQL server.

We at MySQL AB believe in frequent releases to be able to push out new
features quickly to our users.  Because of this we do a new small
release about every three weeks, and a major branch every year.  All
releases are throughly tested with our testing tools on a lot of
different platforms.

PostgreSQL is based on a kernel with lots of contributors. In this setup
it makes sense to prioritize adding a lot of new features, instead of
implementing them optimally, because one can always optimize things
later if there arises a need for this.

Another big difference between MySQL and PostgreSQL is that nearly all
of the code in the MySQL server are coded by developers that are
employed by MySQL AB and are still working on the server code. The
exceptions are the transaction engines, and the regexp library.

This is in sharp contrast to the PostgreSQL code where the majority of
the code is coded by a big group of people with different backgrounds.
It was only recently that the PostgreSQL developers announced that their
current developer group had finally had time to take a look at all the
code in the current PostgreSQL release.

Both of the above development methods has it's own merits and drawbacks.
We here at MySQL AB think of course that our model is better because our
model gives better code consistency, more optimal and reusable code, and
in our opinion, fewer bugs.  Because we are the authors of the MySQL
server code, we are better able to coordinate new features and releases.