On Fri, Mar 25, 2016 at 4:15 PM, Jernigan, Kevin <kmj@amazon.com> wrote:
> 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:
>> 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 more Oracle
> (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.
I worked with one company that was running just about everything on
RAC, and thought that would be a barrier to moving from Oracle.
When we talked about how and why they were using RAC, it turned out
they were basically just using it for elastic resource allocation
-- they were always bringing up new applications and never really
knew which ones would grow to need lots of resources and which
would fail to catch on and would wither away. With that
perspective on it, they realized that VMs and containers handled
that need better than RAC, and an apparently large obstacle to
moving away from Oracle just fell away.
There is always some inertia involved in a change like that, even
with a move to a technology that serves the company better in the
long term; but if they can start down that road they are likely to
find the desire to eliminate different ways to do the same thing a
reason to move away from RAC or similar "lock in" technologies.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
