On Fri, Mar 25, 2016 at 4:15 PM, Jernigan, Kevin <kmj@xxxxxxxxxx> wrote: > On 3/25/16, 4:37 AM, "pgsql-general-owner@xxxxxxxxxxxxxx on behalf of Mark Morgan Lloyd" <pgsql-general-owner@xxxxxxxxxxxxxx on behalf of markMLl.pgsql-general@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
