Moving away from Oracle database? You have got to be joking

SUMMARY:

Are customers seriously lining up to get off Oracle database? That’s the implication from one media source.

Oracle BD schema

A recent article in The Information strongly suggests that some major Oracle customers (Amazon and Salesforce) might be looking to leave the fold. It’s the sort of story that captures your attention for the moment until you realize that it is just a story, not a fact-driven assessment. Think about it.

Building a database sounds like a lot of work and almost a self-inflicted wound but could it be real? Since the start of the year, I have sat with executives from Oracle and Salesforce. Here’s what I now know, based upon those conversations.

According to The Infomation some of Oracle’s biggest customers like Amazon and Salesforce are planning to get the Oracle database out of their businesses. The article suggests that Amazon Redshift and Salesforce’s database research project, code-named “Sayonara,” are both initiatives to accomplish the goal of database independence. Redshift implies a shift (sic) from Oracle, whose main logo color is red, and ‘sayonara’ is the Japanese word for ‘goodbye.’

As evidence, the article observes that Amazon has been working on database technology since Y2K, nearly two decades ago. According to the piece,

Around 2000, Amazon started looking at open-source database alternatives, not to save money but because Oracle’s database was having trouble handling the rapid growth in e-commerce traffic that Amazon.com was experiencing at the time…This resulted in a number of crippling outages, including one in December 2004 that rendered Amazon.com inaccessible for several hours.

Around the same time, Salesforce had a couple of outages for similar reasons but that was a long time ago and Oracle has been working very closely with Salesforce and presumably with Amazon too, to ensure such outages don’t happen again.

Despite the conflation of ancient history, The Information misses some fundamental points that point in the exact opposite direction.

Do it. Dont do it

Database technology is big, convoluted, and expensive to both build and maintain. You can say much the same for operating systems. To paraphrase what the late great comic Richard Pryor said about cocaine, building a relational database might be God’s way of telling you that you have too much money.

It’s good to have alternatives and sometimes you have to make your own. There are many large vendors today that started as side projects because a business needed something that wasn’t available anywhere. That’s not the case with databases; Amazon is reinventing the retail and infrastructure and retail wheels. It has taken forever in tech years. Nearly two decades have elapsed since Amazon’s initial growing pains, enough time for Amazon to decide to fold its database tent.

A business should not go off and provision something for itself that the marketplace can deliver at a fair price. Such a project is defocusing and needlessly siphons money from the bottom line or, from better spent R&D. The cost of developing an item as core to a business as the database is small compared with the opportunity costs inherent in the development. Then, too, the work is never done. Maintenance and upgrades are the gift that keeps on taking and eventually the technology could easily become a dead end.

Critics might say that Amazon and Salesforce are each in direct competition with Oracle. Amazon sells infrastructure as a service and hosts other competitors’ offerings like Microsoft Azure. Salesforce and Oracle directly compete in enterprise front office software and will likely make up the reigning enterprise oligopoly (with Microsoft) at mid-century.

No doubt entering the database market at the grassroots is a common strategy for disruption and Amazon could take some business from Oracle. But despite the standardization inherent in SQL, a database is a decision you live with for decades because it’s so hard to change. Moreover, the technology can easily become an evolutionary dead end supporting a customer base of diehards but not growing much in the shadow of the leader.

What might be driving some of the Oracle antipathies may be the company’s enforcement audits. A group of about 400 Oracle employees conducts technology audits to ensure that customers aren’t violating their licensing terms. Those terms can be hard to understand or get right. For instance, Oracle has done a great deal of business over the years in the last week of a quarter wheeling and dealing to make quota. Some of those deals might not have been as well crafted as they would have liked and the use terms may have been set rather loose. What’s more, Oracle is known to change definitions, in essence moving the goal posts. This can have the effect of unintentionally trapping customers in a licensing problem.

As a result, there may be a real need to revisit licenses to see if all of the parameters have been adhered to. Understandably, the practice is not eagerly embraced by many customers and especially those who find themselves on the hook for additional license and maintenance costs. The solution is not likely found in enforcement processes or in simplified pricing but in customers transitioning to the cloud where usage is well defined, for example, by the seat. Typically, compliance issues are much less likely to occur when operations are conducted in the cloud. But don’t look for changes in the audit process any time soon.

Oracle’s traditional pricing is a perfect foil for demonstrating savings when customers move to the cloud; so it’s unlikely the company would do much at the moment to modify pricing. Also, the company spends billions each year on R&D and the cash has to come from somewhere. So customers looking for better pricing or less convoluted pricing are best off transitioning to the cloud and avoiding the conversion costs. In those terms, rolling your own database seems like an evolutionary dead end.

My take

Moving away from your database vendor would be like cutting off a foot; self-destructive and painful. More to the point, building a me-too product and entering a full-on competition with the established leaders, is a significantly retrograde step with little tradition of success. Beyond the relational database, there are many new wrinkles that offer attractive niches such as virtual machines, bare metal servers, serverless technologies and micro apps. But I am not seeing a great deal of competition heating up in that space.

I met Parker Harris, co-founder and CTO of Salesforce a week ago at a Salesforce sponsored analyst event. When he was asked about moving away from Oracle, Harris said,

We have a good relationship with Oracle and we use a ton of it. We are not getting rid of the Oracle database. We are working on technologies that add capabilities around the edges, like sandboxes. We will have SQL Server and Oracle for a long time.

Those are hardly the words of a revolutionary wanting to divest from Oracle database.

I also spent a day with Oracle executives who laid out their roadmaps for a major information utility architecture including Infrastructure as a Service, Database as a Platform, Autonomous Database, Security as a Platform and a great deal more. The sheer volume of their initiatives is mind-blowing and it speaks to the emerging demands for secure information processing emerging now that will be hard requirements for any enterprise software vendor after 2020.

So, to me, the time for entering the database market ended in about 1989. The rest of the talk is just that. Talk. And, quite frankly, The Information is bloviating on a story that really doesn’t have legs.

Image credit - screenshot

Disclosure - Oracle and Salesforce are premier partners at time of writing

    1. Pascal Desmarets says:

      Pretty amazing that the article does not consider the existence of NoSQL databases. Have you heard of MongoDB, AWS DynamoDB, Couchbase, Azure Cosmos DB, Cassandra, Google Firestore, Elasticsearch, Neo4j, MarkLogic, etc??

      Companies don’t have to build their own databases. There are now plenty of viable, stable, and affordable alternatives…

      1. James Brown says:

        The article is focused on relational databases. Contrary to common belief, these are not in direct competition with each other as they solve completely different workloads. Recently i have had to migration from NoSQL to Relational due the kinds of data sets i have.

    2. Harald Nehring says:

      This might have all been true in a pre-cloud world, where enterprises had to make conscious decisions about the database tech they want to run many/most of their apps on. This in turn forced application vendors to support their customer’s database choice.

      In the cloud nobody’s asking “what database does this service run on”. It’s got to be up to the task, scale like mad in all directions (size, speed, load, …) and economically viable (can’t pay hefty per user licenses for a low/no cost mobile service for millions of users).

      That’s why many cloud service providers don’t just rely on a single database to handle it all – there might be a record keeping back end database of a more traditional type in play, but it’s often augmented by big data stores, optimized analytics engines etc. for application specific loads.

      And don’t forget – ORCL has lost a former staunch supporter of its database with SAP, who’re moving major application so HANA and into the cloud. Where only the business outcome matters.

    Leave a Reply

    Your email address will not be published. Required fields are marked *