1. 13

  2. 17

    IMO this is not a balanced or trustworthy article. I don’t know too much about databases, but this reads like he’s used only Postgres for the past 20 years. Very fanboyish in a way that makes me very suspicious of all his claims. Two that really leapt out at me:

    So, you want NoSQL, Riak, REACT, Redis, Mongo, etc.? PostgreSQL does all that. Admittedly not with all the bells and whistles of all of the original products. For example, PostgreSQL doesn’t create new shards for you for any of those. That’s still a manual process. But then again, there’s always pg_partman. . . […] I would have a hard time thinking of a feature that I want that PostgreSQL doesn’t have, or that there isn’t a well known extension to provide.

    This is the “it can do everything so it’s better than everything” argument. Same as people who say lisp is better than language X because you can just hack in X’s features with macros! Completely misses that something designed for specific task is probably going to be better at it than a random general-purpose database that can just happened to do that task.

    PostgreSQL is extensively tested. No, that’s not saying it strongly enough. PostgreSQL is exhaustively tested. Every bug is met with a test to verify it’s existence, and code is written to satisfy the test. New features are written by the creation of tests (and documentation) first, then coded until the feature appears.

    This is like the bare minimum of testing you would expect for a database. By comparison, SQLite has three test harnesses, crash testing, multiple failure testing, multiple fuzzers, mutation testing, and optimization testing.

    PostgreSQL is only released when ALL of the regression tests pass. This provides for “0 known bug” releases.

    I checked around and the only person making the “0 known bug” claim is this guy.

    1. 2

      Transparent Security

      PostgreSQL has a security mailing list. The PostgreSQL project learns about the intrusion vectors at the same time that everybody else does. Nothing is hidden, and anything that is found is worked on at a rate that makes the commercial vendors’ heads spin. Don’t be fooled by shorter defect lists published by the same vendor that provides the software under scrutiny.

      This means that all known attack vectors are handled as soon as they are made public. This kind of security responsiveness is not even contemplatable in the commercial market. For commercial vendors, secrecy until the problem can be addressed is vital to the remediation. PostgreSQL gets no such relief, and that’s fantastic for you.

      This part isn’t necessarily true either. In 2013, cloud provides were given early access to information about a vulnerability: https://www.postgresql.org/support/security/faq/2013-04-04/

      Was taking the repository private while this security discussion was ongoing the proper thing to do?

      Given the severity of the vulnerability, the PostgreSQL Core team deliberated and determined the security risk posed by having the source code for the fix available before the packages were made available outweighed the public’s interest in having immediate access.