Re: PostgreSQL advocacy

On 3/25/16, 4:37 AM, "pgsql-general-owner@postgresql.org on behalf of Mark Morgan Lloyd"
<pgsql-general-owner@postgresql.orgon behalf of markMLl.pgsql-general@telemetry.co.uk> wrote:
 


>Jernigan, Kevin wrote:
>> On 3/22/16, 8:07 AM, "Bruce Momjian" <bruce@momjian.us> wrote:
>
>>>
>>>                         HA   Scaling  Upgrade Add/Remove
>>>        Oracle RAC       50%     50%    easy    easy
>>>        Streaming Rep.  100%     25%*   hard    easy
>>>        Sharding          0%    100%    hard    hard
>>>        
>>>        * Allows read scaling
>>>
>>> -- 
>>>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>>>  EnterpriseDB                             http://enterprisedb.com
>>>
>>> + As you are, so once was I. As I am, so you will be. +
>>> + Roman grave inscription                             +
>> 
>> Implementing RAC-equivalent functionality is extremely hard, as evidenced by the lack of any directly comparable
capabilityfrom any other relational db engine, until the release of IBM DB2 Shareplex a few years ago. And given the
improvementof PostgreSQL and other open source solutions over the past 20 years, it’s not clear that it makes sense to
gothrough the initial design and implementation work and then the ongoing maintenance overhead - most of what RAC
providescan be achieved through other existing capabilities. 
 
>
>Hearing what IBM's strong points are is always useful, since the various 
>flavours of DB2 obviously have facilities to which other databases 
>should aspire. As with Oracle, DB2's strong points aren't really 
>well-publicised, and things are further complicated by the variant 
>terminology which IBM has evolved over the half century they've been 
>building mainframes.
>
>> While I’m not sure that the percentage breakdowns in your chart are totally accurate, I agree with the general
assessment,except for the highest-end applications which have zero-downtime requirements which can’t be met with
streamingreplication: the overhead of synchronous replication limits scalability, and the failover time for moving from
primaryto a failover target is significantly slower than RAC - which can be literally zero if configured correctly.
 
>> 
>> The higher-level point that I think is important is that while I may be able to win technical arguments that RAC is
betterfor certain high-end extreme workloads - and maybe I can’t even win those arguments ;-) - the real issue is that
therearen’t very many of those workloads, and the PostgreSQL community shouldn’t care: the vast majority of Oracle (and
SQLServer etc) workloads don’t need all the fancy high-end RAC capabilities, or many of the other high-end commercial
databasecapabilities. And those workloads can relatively easily be migrated to PostgreSQL, with minor disruption /
changeto schemas, data, triggers, constraints, procedural SQL…
 
>
>What I've seen so far suggests that if MS is positioning SQL Server to 
>challenge Oracle, it's basically looking for low-hanging fruit: in 
>particular supplementary databases which corporates have put onto Oracle 
>out of habit but which quite simply don't need some of the higher-end 
>facilities for which Oracle is harvesting revenue.
>
>Just because a corporate has a hundred sites cooperating for inventory 
>management doesn't mean that the canteen menus have to be stored on 
>Oracle RAC :-)
>
Right, but often the customer has paid for a site license, in which case the IT department will just keep spinning up
moreOracle (or SQL Server or DB2) databases when requests come in - even if it’s overkill for the proposed use case /
workload,it’s less work if IT only has one database technology to support.
 

For all kinds of often cloud-y reasons, there have been recent stories in the press of many enterprise customers not
renewingtheir site licenses, in favor of cherry-picking their biggest / hardest workloads for the commercial databases,
andthen moving the rest to open source, often though not always to PostgreSQL, and often in the cloud.