How Accurate is Seeking Alpha on the Relative Decline of SQL?

Executive Summary

  • Seeking Alpha proposed interesting things regarding SQL vs. NoSQL.
  • In an article, they covered commercial database growth and questioned whether commercial SQL databases had hit a wall of diminishing utility.
  • Seeking Alpha’s prediction for NoSQL is, in part, due to the advancements in hardware that allow data to be stored at a lower level of normalization.
  • The article also points out the marginalization of mission-critical application databases, asks the question of the costs of Oracle and DB2.

Introduction to SQL Versus NoSQL

Significant changes are occurring in the database market. In this article, we will cover a very interesting proposal made in an article regarding these changes from Seeking Alpha.

SaaS Vendors and Open Source Databases

“The vast majority of SaaS providers today either use an open-source database, or, as is the case with SaaS HCM vendor Workday (NYSE:WDAY), develop their own. Every user of an on-premises enterprise application, including one of the five core client-server application categories: ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), HCM (Human Capital Management), SCM (Supply Chain Management), and BI (Business Intelligence) applications, which moves to SaaS therefore eliminates a commercial database seat, and with it, the maintenance/support and future upgrade revenue it would have generated. Even an enterprise seat that moves to will generate far less revenue for Oracle than that seat did when it was deployed on-premises.”

This is a fantastic point. If you use SaaS, the database question is taken out of the equation. A true multi-tenant database means that there are fewer databases used. Therefore, even if Oracle is used (and Oracle 12c has added much multi-tenant functionality), fewer instances of Oracle 12c are required.

Commercial Database Growth?

“Hence, we believe the enterprise migration to SaaS/cloud is highly deflationary for commercial-database revenue. Further, we are still early in the migration from client-server to SaaS/cloud. Depending on which research one believes, this migration is only 10% to 25% complete and is only just beginning to impact more mission-critical applications – such as ERP – that are more likely to be running on higher-end SQL databases (including those from Oracle and IBM, and to a lesser extent, Microsoft).”

True, as SaaS picks up speed, this issue becomes a stopping point in growth for commercial databases. This hits Oracle and IBM the hardest.

Commercial SQL Databases Hitting Diminishing Utility?

“Commercial SQL Databases are Not Well-Suited to Handle the Most Compelling Emerging Use Cases. After SQL was standardized in 1987, it went unchallenged for over 20 years in defining how data was organized, searched, and sorted. However, in the mid-2000s, colossal tech companies began running into the limitations of SQL databases in handling both the sheer volume and varying structure (or lack thereof) of the data that they wanted to preserve, navigate, analyze, and serve up on-demand to their users/customers.”

This is true. The market share for SQL databases is declining as a percentage of all databases used.

“Amazon (NASDAQ:AMZN), Google (NASDAQ:GOOG) (NASDAQ:GOOGL), LinkedIn (LNKD), and Facebook (NASDAQ:FB) each solved its own scaling problems by developing and implementing its own database software that broke with the constraints of the SQL standard.”

Hard to argue with that.

The Decline of SQL and the Rise of NoSQL Due in Part to Hardware Upsizing

“NoSQL Databases and Schema-on-Read Processes Are on the Right Side of Moore’s Law; SQL and Schema-on-Write Are on the Wrong Side. In general, NoSQL databases are substantially more processor, memory, and storage intensive than SQL databases, even after considering the fact that they relax many of the constraints that SQL places on how data is organized. Though NoSQL database architectures existed well before 2005 – at least, in theory – there was simply not enough processing power, memory capacity, and storage space for them to be put to practical use outside of academia.”

I had not considered this before, but SQL databases require a lot of effort to be placed into organizing them. But with more hardware, one can reduce this “energy input” for many applications of the database.

Hardware Restrictions Meant More SQL DBs?

“During the comparatively processor/memory/bandwidth-starved 1980s and 1990s, adherence to the more-rigid SQL standard was effectively compulsory to ensure the performance and reliability that enterprises needed in order to migrate their applications, especially those more mission-critical applications, from mainframes and minis to the more-distributed and network-dependent client-server architecture.”

This logically follows nicely.

The price paid for SQL’s acceptable performance and reliability was driven by:

“The overall inflexibility of the data structure called a schema;

The onerous requirement to define that structure prior to the deployment of the database and its associated applications;

The difficulty in changing that structure over time in order to capture different kinds of data, and to better reflect changes in the structure of the data and in the organization of the enterprise.

The requirement for a schema-on-write process, which fits data into the schema as it is inputted, as opposed to schema-on-read, which is simply dumping data into a big “container” and organizing it later into a schema.”

So basically a lot of overhead and work. This is the work of the database administrator.

No SQL Flexible Schema Benefits

“Over time, however, Moore’s Law-driven improvements in processing power, memory capacity and speed, storage capacity and speed, and network throughput have made the rigidity of the SQL standard and the requirement for schema-on-write processes increasingly less necessary and will continue to do so. Hence, with every Moore’s Law cycle, SQL and its resource-efficient schema-on-write process loses its competitive advantage, while NoSQL, with its relatively resource-inefficient but much more flexible schema-on-write process, becomes increasingly free from the constraints that prevented it from being adopted in the first place.”

Right, resource inefficiency, becomes less of an issue with more computational resources, meaning human resources can decline.

“In-Mem Possibilities and the Elimination of HDD Compromises. When SQL was standardized, hard disk drives (HDDs) were the only cost-effective storage medium that could be accessed in real time. Therefore, much of the fundamental code written into SQL database software is designed to accommodate the shortcomings of HDDs, such as the slow speed with which they can read and transmit requested data into memory and their relatively higher failure rates – at least, compared to the major solid state components of a system such as the CPU, memory, and network throughput. Now that SSDs are rapidly becoming a cost-effective replacement for HDDs, much of the design and certainly much of the code of legacy SQL database software that made such compromises in order to accommodate comparatively much slower HDDs is now rendered unnecessary.”

This is a constant feature of computer systems. Early design decisions are made to fit with the hardware of the time. When hardware improves, the earlier design decisions no longer make sense.

Leveraging SSDs

“In contrast, many NoSQL databases are written so as to take maximum advantage of SSD storage and will likely be updated to take advantage of even faster-emerging non-volatile memory technologies such as Intel (NASDAQ:INTC)/Micron’s (NASDAQ:MU) 3D xPoint, which is just now becoming commercially available. We believe that, given the strong requirement to maintain compliance with the SQL standard and maintain their own backward compatibility, SQL database vendors will not be able to optimize their code for SSDs nearly as fast as many of the open source projects will be able to, putting them further at a competitive disadvantage – a classic example of Clayton Christensen’s “The innovator’s dilemma.”

This is a true insight. It means that SQL vendors are at a disadvantage in making the transition due to legacy designs. That is, designs developed for a different hardware era.

Marginalizing Mission Critical Application DBs

“Increasing Availability of “SQL Methadone” Solutions for Weaning Enterprises Off Expensive Commercial Databases. We are seeing an increasing number of software tools and services designed to help enterprises migrate from commercial SQL databases. Even the most mission-critical applications running on an Oracle or IBM database can be increasingly surrounded, “quarantined”, and dismantled over time, much like what happened to many of the legacy mainframe applications during the shift to the client-server architecture in the 1990s.”

This is a fascinating observation. This brings up many interesting questions as to how complicated or easy this process is. Also, for what uses is this currently being performed? What are the larger implications?

“While SQL databases from the likes of Oracle, IBM, and MSFT will survive in some enterprises for many more years – again, much like mainframes – they will be increasingly marginalized and cost-reduced as much as possible. We see many of these tools maturing already within the Hadoop ecosystem, which already has multiple ways to integrate with SQL databases and/or put SQL interfaces and querying ability on NoSQL databases. In our opinion, this is a very similar development to the early-1990s emergence of multiple ways to integrate mainframe applications with PCs and client-server applications.”

This brings up the question of whether not just Big Data applications, but typical applications — such as production planning, accounting, etc. applications can also transition to NoSQL databases.

What is the Cost of Oracle or DB2?

“The main benefit of NoSQL is they are usually open source and either completely free, or relatively low cost since some support is usually purchased. Most people don’t realize how expensive Oracle and DB2 are, often costing a license fee of $1 million per server, plus $200,000 per year for ongoing support after that. Most enterprise applications need more than one server for fault tolerance, staging, QA, testing, development, etc (although licensing costs for non-production installations are often less than the production server). – From Mark A commenting on the article The Death of the Commerical Database Oracle’s Dilemma.”

This is, in part, driving the move away from NoSQL.

Future of Oracle Database Growth?

Seeking Alpha calls out what the shift in the market means for the biggest player in that market.

“We see the $29.6b commercial database market contracting 20-30% by 2021, and do not believe Oracle (NYSE:ORCL) can transition its revenue streams (from legacy commercial database to cloud-based subscription offerings) fast enough to offset the decline of this market, which represents a major legacy core of its revenue.”

That makes sense. Oracle has been proposing that its cloud revenues will more than make-up for any losses. Seeking Alpha also points out that IBM will also lose market share, but that IBM is far less dependent upon its database business for its overall revenues than Oracle.

Checking the Database Growth Figures with DB-Engines

This is an excellent article by Seeking Alpha. This author has an impressive insight into the topic of the material. Now the question is checking to see DB-Engines see if this is occurring the database growth rates.

Of the top 30 databases, as ranked by DB-Engine, the following applies:

The Rate of Growth for SQL Versus NoSQL?

To test the hypothesis presented by Seeking Alpha we took these top 30 databases (where most of the growth movement happens in the database market, and we averaged the growth rate for the 18 SQL databases, and then the 12 NoSQL databases (which includes all of the database types listed in the previous graphic that are not called RDBMSs)

We came up with the following growth rates from July 2016 to 2017.

  • SQL Database Growth Rate: +3.4%
  • NoSQL Database Growth Rate: +8.6%

So NoSQL databases are indeed growing faster. But SQL databases are not declining. But what is happening is something a bit different. We then averaged the growth of the proprietary databases in the top 30 list and the open source. As of July 2017, there were 11 proprietary databases in 19 open source. The growth rates broke down as follows:

  • Proprietary Growth Rate: -1.2%
  • Open Source Growth Rate: +8.4%

Therefore, the growth is mostly attributed to open source databases, rather than to NoSQL databases. The NoSQL databases have a stronger tendency to be open source. And of course, open source databases cost less than proprietary.


This is an excellent article by Seeking Alpha, with many great insights.

However, the central hypothesis that SQL databases are losing market share to NoSQL does not seem to bear out in the numbers that are supplied by DB-Engine. What seems to be the case is that there is a shift to open source databases, and most of the NoSQL databases are open source.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.


The Real Story on ERP Book

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.

ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.

Break the Bank for ERP?

Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.

By reading this book you will:

  • Examine the high failure rates of ERP implementations.
  • Demystify the convincing arguments ERP vendors use to sell ERP.
  • See how ERP vendors take control of client accounts with ERP.
  • Understand why single-instance ERP is not typically feasible.
  • Calculate the total cost of ownership and return on investment for your ERP implementation.
  • Understand the alternatives to ERP.


  • Chapter 1: Introduction to ERP Software
  • Chapter 2: The History of ERP
  • Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
  • Chapter 4: The Best Practice Logic for ERP
  • Chapter 5: The Integration Benefits Logic for ERP
  • Chapter 6: Analyzing The Logic Used to Sell ERP
  • Chapter 7: The High TCO and Low ROI of ERP
  • Chapter 8: ERP and the Problem with Institutional Decision Making
  • Chapter 9: How ERP Creates Redundant Systems
  • Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
  • Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
  • Chapter 12: Conclusion

How to Understand Why S/4HANA is a Poor Fit for the Cloud

Executive Summary

  • There is a poor fit between S/4HANA and the cloud, which is hidden by the fact that SAP commingles S/4HANA Cloud with S/4HANA on premises.
  • For this article, we needed to cover ASP (Application Service Provider) versus “single =tenant” versus “private cloud.”

Introduction to The Real Story on Cloud and S/4HANA

While researching the actual history of S/4HANA implementations, something that came to the surface is how rare it was for any S/4HANA implementation to be in the cloud. This is curious because so much of SAP’s marketing around S/4HANA has been used promoting S/4HANA Cloud as an application that is flexibly deployed. In this article, you will learn the real story on the applicability of the S/4HANA Cloud to the cloud.

What is the Cloud or SaaS?

Many people think that the cloud, aka SaaS, is undefinable and or that any claim by a vendor that something is cloud should be accepted as true. However, SaaS is very well defined. The terms SaaS and cloud are quite often used interchangeably. So while not entirely overlapping, they will be considered synonyms for this review.

Important supporting words are as follows:

  • Hosted: This means that the application is on servers that are outside of the company that uses them. It does not mean anything more than that. Sometimes hosted is used to be considered distinct from SaaS. But this is inaccurate. SaaS is a particular modality of hosting, and the benefits of SaaS do not generalize to any application that is hosted.
  • Application Service Provider (ASP): This means that the application is provided by an outsourced company that is not a SaaS/cloud arrangement.
  • Single tenant: This is where a single customer is supported by a hosted application.
  • Multi-tenant: This is where multiple customers are supported by hosted applications.

Understanding the Interrelationships of SaaS

The interrelationships will be reviewed in this paper.

  • The Public Cloud
  • ASP
  • Private Cloud

The Public Cloud

The term public cloud is rarely used except when in the same sentence as the term private cloud. In the vast majority of cases, the term public cloud is used without a modifier, i.e., just the “cloud.”

ASP (Application Service Provider) Versus “Single-=Tenant” Versus “Private Cloud”

All of these terms have different origins. All are adjectives to define better a software instance, which is a “hosted” service with a single tenant as opposed to multi-tenant, which is one of the basic requirements for SaaS.

The Private Cloud

The problem with this term is that “private cloud” is that it’s a bit of a misnomer because the word does not fit the definition of cloud computing. Cloud computing both implies and requires shared resources.  Regardless, private clouds are often lauded for their improved security. Still, they have a fundamental limitation. They do not offer the many benefits of the cloud, public cloud, or SaaS, and they do not scale well.

The Wikipedia Definition of Private Cloud

Wikipedia has a good description of private cloud, which states “they have attracted criticism because customers “still have to buy, build, and manage them”. And thus do not benefit from less hands-on management, substantially “[lacking] the economic model that makes Cloud computing such an intriguing concept.”

SAP’s marketing materials show many cloud-based third-party applications. However, SAP does little of its hosting except for its newly acquired applications that were already cloud-based before they were purchased. Therefore, most of SAP’s database and applications revenue is from applications not in the cloud. S/4HANA Cloud matches this pattern by having very few customers. 

There is no doubt that Concur, Fieldglass, Ariba, and SuccessFactors are delivered via SaaS. Those vendors have traditionally been delivered through SaaS. But they are much more straightforward applications than an ERP system. However, S/4HANA Cloud is not delivered through SaaS to any substantial number of companies or any companies of considerable size. The larger the company, generally the larger and more complex the requirements, and the more need for customization, which moves the company away from being able to use SaaS ERP applications, which includes S/4HANA Cloud.

  • Any level of complexity and customization can be supported by hosting the ERP system or what is called a private cloud.
  • But then almost all the advantages of SaaS are lost. All that is done that differentiates this from on-premises is the hardware switches locations from the customer to the vendor.

No Customization a Foundation for SaaS

SaaS customization was first reviewed above in the section on multi-tenancy (i.e., One Code Base — Multi and Single Tenancy). SaaS’s underlying data model and system architecture are not customizable. “No Customization” allows the SaaS software vendor to spend less time dealing with various platform patching, compatibility issues, and individual upgrades.

A true SaaS vendor is supposed to upgrade a single instance, which then updates all customers simultaneously. This should then imply fewer support expenses.

The Reality of No Customization of And ERP System

SaaS applications tend to predominantly be simple applications that are not customized for each client. The fertile areas of SaaS tend to be applications such as the bill of materials management, CRM, HRMS, travel and expense, online meetings, and email.

However, the current trend indicates that software vendors are increasingly moving more complicated applications, which have a long history of being customized to the cloud.

That being said, we do not foresee that the need for customizations will abruptly come to an end just because applications move to the cloud.  For example, SAP’s ERP system, called ECC, is either highly or moderately customized in 92 percent of instances. SAP’s replacement for ECC, called S/4HANA, will be made available in the cloud.

However, serious questions remain concerning customization and how these customizations will be ported to a SaaS environment as proposed by S/4HANA Cloud. Such issues are already starting to emerge.


For example, the following excerpt from a recent review of S4 HANA Cloud shows these questions arising:

“I’m examining the degree of “SaaSiness” within the scope of S4 HANA – I’m not using it as a standard in comparison to other non-SAP SaaS applications. There are definitely other “purer” SaaS applications in the market but such a comparison isn’t the focus of this piece. Although there are theoretically pure “Private” and “Public” versions of S4 HANA, company-specific manifestations will probably emerge that combine various characteristics of each extreme.

For example, one SI may allow greater customizing for customers at the expense of a weaker SLA or at a higher cost.  Furthermore, a company/SI could have multiple S4 HANA-related offers to meet the needs of different customers/business requirements.” – Diginomica

In my view, this industry expert is granting SAP SaaS status before SAP has proven this capability. This expert even states that he is not focusing on how pure S/4HANA is for SaaS because it is not the focus of his attention. However, he is assuming S/4HANA Cloud is SaaS or presenting it as such. I do not see who would care what the focus of his attention is or isn’t. Something either meets a definition of a term, or it does not.

Will SAP Be Actually Providing Hosting?

In most cases, though, SAP will not be doing the hosting. There may be cases where the instance is hosted by a firm such as AWS. (In that case, it is also not multi-tenant.) This expert points this third-party hosting capability out in a different part of his article:

“However, there is no reason why a partner couldn’t duplicate this offer for its customers – even exploiting HANA’s multi-tenancy feature included as part of SP9.”

S/4HANA is currently going through a rapid development cycle, with new functionality being released each quarter. The S/4HANA Cloud version lags the S/4HANA on-premises version. It is likely that even when this cycle slows, there will be SAP customers on different versions of this ERP system.

Can S/4HANA Be a Cloud/SaaS Application?

S/4HANA will, in most cases, be implemented with customization requirements. This precludes S/4HANA from being a true SaaS application. SAP also does not follow most of the other SaaS characteristics, and this categorizes S/4HANA as a non-SaaS application. Only the smallest customers will be able to use S/4HANA in a non-customized way. However, S/4HANA is a Rolex watch regarding cost and complexity. ECC had the highest TCO of any ERP system.

See details on the TCO of ECC in the online TCO calculators at this link.

A Top Cloud ERP Vendor’s View on Customization and SaaS

I wanted to get another viewpoint on this conflict between customization and SaaS delivery and S/4HANA Cloud, and the standard requirement for customization in the ERP software category. So I reached out to Rushabh Mehta, who leads ERPNext and whom I happen to know, has quite a few customers on SaaS delivery for their software. He had this to say on the topic.

“The problem of mass customization, which seems intractable from a pure SAAS point of view, is solvable with a plug-in architecture. An Cloud ERP does not have to be pure multi-tenant, but multi-tenancy can be built on basis of virtualization so you can technically run a multi-tenant cloud with each customer in a separate VM running own set of plug-ins. This would still be some kind of a hybrid “cloud” as long as all customers get upgraded simultaneously. I think it is possible, though I have no idea how “pluggable” is the S/4HANA architecture is.”

Pluggable means that extensions or add-ins from outside vendors can be easily added to the core product. S/4HANA architecture is not pluggable. It is, in fact, the exact opposite of pluggable.

This is a critical distinction to understand because SAP has, for years, made it difficult to connect applications to its software. This is used to create a barrier to entry to push customers back to using other non-ERP SAP applications. Software companies develop integrations to SAP ERP, but these are not plug-ins, so that is a different topic.

ABAP Customization of ECC

Customization is written in ABAP to pull in functionality from pre-existing applications the company wrote, or enhancements to ERP. These are one-off and are not shared or at least very little shared between clients.

Let us get back to another quote from Rushabh:

“From the other side, I don’t think any vendor has been able to fix this problem, even for small businesses. The reason in my view is that the incentive for revenue is stacked up in the favor of large-scale customization (emphasis added). So from the SAP point of view, even if they could pull of a common code-base across the cloud with a really cool plug-in architecture, their heart can never be in it, because it’s a recipe to kill their revenue. Companies can spend ~1% of their annual expense on their ERP system and SAP wants to collect all of that tax/rent.”

Is SAP Going to Open Up?

SAP will often give lip service to opening an allowing more interoperability with other vendors. For instance, they talked a good game with SOA. They talk a good game about partnering with software vendors. However, they undermined those partnerships and tried to get companies not to buy from their “partners.” I covered this topic quite extensively from the perspective of something called indirect access in many articles, one being How SAP is Now Strip Mining its Customers.

“That is the core of the problem – not only for SAP but also the entire ERP industry – There is just too much money on the table (esp for large companies) and they see no reason to push for mass customization when customers are ready to pay for re-inventing the wheel every single time.”

SAP does not make much money from customizations, but the SAP consulting companies do.

My take is a bit different from Rushabh’s here. My view is that SAP can only bring out so much functionality, and it cannot (obviously) meet all requirements. To Rushabh’s earlier point, SAP has no plug-in architecture to allow other companies to come in and develop add-ons to ECC/S/4HANA. The approach with SAP been one-off customizations.

Advice on Enjoying the S/4HANA Quiz

To see the full screen, just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.



SAP’s strategy with S/4HANA Cloud, or delivered by SaaS, does not make any sense. It is not currently working and is unlikely to work in the future. The strategy appears to have been hatched by SAP marketing to appeal to Wall Street and to seem leading edge, without consideration for what makes an actual SaaS solution beneficial over a hosted or private cloud.

We predict that SAP will continue to pretend it has a viable “SaaS” option available. But will merely end up hosting/private cloud managing S/4HANA for some companies because the benefits of doing so will be to continue to obtain a higher multiple for their stock price.

See our The S/4HANA Implementation Study. for real story and details on actual S/4HANA implementations.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.