How Accurate are SAP’s Arguments on Code Pushdown and CDS?

Executive Summary

  • SAP on has made bizarre proposals regarding code pushdown (aka stored procedures) and Core Data Services.
  • As with Oracle, SAP is using CDSs to restrict the options of its customers to better lock them into buying SAP.

Introduction: How Truthful is SAP Being on Code Pushdown?

SAP has made a lot of noise about how important its code pushdown (aka stored procedures) in HANA are. However, an issue that has begun to arise in how SAP has begun to use the term to describe things that do not actually code pushdown. You will learn what is true regarding code pushdown.

What is Code Pushdown?

The first place to begin of course is “what is code pushdown.”

Code pushdown is an SAP term for putting code that was previously in the application layer into the database layer.

How SAP is Now Using the Term

As stated by a colleague.

“Code that was pushed down to the database becomes even more pushed down by “filter push down”, “limit push down” and “aggregation push down” This is plain old basic “anyDb” SQL wisdom. Reduce the amount of data as early as possible, especially before you join subqueries, that is at the “most inner” or “lowest” level of your SQL. “Filter push down”: filter each result set to be joined BEFORE you join them, do not join large sets and filter afterwards. I learned this in an “anyDb” administration and performance course about 15 years ago, and even then it wasn’t new.”

Multilevel Push-Down?

The first question that should arise when reading this is how is it that code has to be pushed down multiple levels in the database?

If the code is “pushed,” it is removed from the application layer and inserted into a table. Is there a level below a table? What is this quantum physics?

What SAP means is simply the reduction of data, not actually pushing code.

SAP on Core Data Services

SAP has published a document on ABAP Core Data Services of CDSs that can be found at this link.

But some of the things written in the document are required further elaboration.

For example, it states that Fiori apps are easy to create.

“Based on the OData exposure of CDS described above, it is then rather straightforward to create an SAP Fiori app using the development framework SAP WEB IDE (either locally or within SAP Cloud Platform). As depicted in Figure 4 the SAP Fiori User Interface connects to SAP Gateway using the OData services.”

The idea being the Fiori app will connect to the CDS view. The CDS is a database view with stored database functions that enable the retrieval of data. The idea is to improve on the limited ABAP dictionary views versus anyDatabaseViews have had for decades.

But instead of presenting CDSs as “catching up” with competing offerings, SAP decided to provide a deceptive explanation for the logic of CDSs. This is taken from the document ABAP Core Data Services on AnyDB.

“The CDS framework was introduced to leverage the computational power of HANA DB. Nevertheless, it can also be used with all other databases that support SAP NetWeaver (called anyDB in the following). This guide gives hands-on information on how to implement, run and optimize CDS based applications on anyDB.”

What is a Core Data Service?

A core data service is an enhancement to SQL that is a new data modeling infrastructure. This means the data models are defined and consumed in the database rather than the application.

How HANA Pushes Down CDS

However, there are those with considerable database expertise that suggest that HANA driven CDS enabled functionality pushed down to HANA will likely not end well in the longer term. In fact, this is not at all now. Oracle Retail used PL-SQL functionality to push down code into the database from the application. Similar to HANA the logic was for performance reasons.

SAP IS Retail largely sustained more clear separation of duties between the SAP application, NetWeaver and RDBMS tiers, which also enabled AnyDB choices. The issue with the Retek/Oracle approach which tightly linked together the application code as that any client facing customizations, and the application/database versions, made **future upgrades very complex and costly**.

Essentially vs SAP they became effectively “re-implementations” vs supporting technology upgrades that were possible with SAP NetWeaver and SAP IS Retail. And then comes the issue of lock-in.

The Lock In To HANA

One of these database experts stated the following about HANA’s CDS.

I’m personally nervous where the whole HANA driven application to database functional push down will take clients in the long term, for sure they become firmly locked into HANA and any aligned commercial terms.

Reinventing the Wheel?

That makes it sound like SAP is bringing something that did not exist before — both for HANA and for AnyDB. The clear statement here is that other DBs can benefit from CDSs — making it appear as if CDSs are an innovation, not that they are bringing HANA to par (or attempting to do so) with AnyDB libraries.

That is one problem. The second is the phrasing that

“CDSs were designed to leverage the computation power of HANA, but nevertheless they can be used for other databases.”

This implies that other databases do not have HANA’s computational power. But let us leave that to the side for now.

The point we are emphasizing in is the presentation by SAP of CDSs as if other databases do not already have what CDSs offer. Clearly, it will take years for CDSs to reach parity with anyDatabaseViews.

Cost to Create Fiori Apps

Normally Fiori apps are extremely expensive to create, as was even pointed out in the Forrester study that SAP paid for, where Forrester states that Fiori apps should be used standard. This was addressed in the article What is Actually in the Fiori Box?

And we have numerous stories of the costs of making custom Fiori apps. Basically, this is not happening on projects to any significant degree. Customers that are sufficiently misinformed to customize Fiori apps normally soon run out of money. But these are custom Fiori apps with some complexity. Other Fiori apps are much easier to create than others, as observed by our colleague.

“A simple Fiori app consisting of a drill-down table (filterable, sortable, groupable) and navigation to a detail form is quite easy to build as long as you do not need anything extra. Fiori provides “SmartTables” and “SmartForms” widgets, their behavior can be controlled by annotations/properties in the metadata of OData services (e.g. filterable, sortable, label). These annotations can be defined at the level of the CDS View already (@Filterable, @Sortable, @Label) and are propagated to the OData service that can be generated from CDS Views by some SAP magic. This works quite well for Fiori Apps with almost no UI logic (especially drill down tables with detail views, no edit) that are built once and never touched again. However if you modify the data model you usually are best of when you rebuild your Fiori App from scratch.”

Laying Out Intelligent Fiori Usage

So if Fiori is laid out in terms of usage it is:

  • Use the standard Fiori apps, although those Fiori apps are quite limited (See the article Strange Changes to the Number of Fiori Apps to find out how SAP has exploded and exaggerated the number of Fiori apps.
  • Potentially use the SmartTable or SmartForm Fiori widgets to develop reporting apps.
  • Do not customize any Fiori apps that have any complexity, so business logic, data complexity etc.

The vision being pitched is to use the CDS and then do what you want in Fiori. There is a big question as to whether that will actually happen. If SAP was happy with customers using an efficient non-SAP app development environment then maybe, but then, SAP will dissuade that from happening.

Secondly, another observation about the CDSs is from a colleague.

“This way offers you a clean layered application and the chance to write unit tests without database persistence. SAP are throwing away accepted architecture paradigms. CDS are OK to look at and analyze (join, aggregate, partly filter) data. That’s it. CDS is a framework, not new technology.”

This brings up the topic of whether CDS will ever really catch on, or if they will end up being just another item that SAP introduces that just falls to the wayside.

The Benefit to Stored Procedures / Code Pushdown

CDSs as with stored procedures are a form of code pushdown. However, overall, we are still lost as to why SPs are a good thing when the discussion of SPs is really about tradeoffs. This topic is actively debated among different with expertise in the area and there is not one clear answer. We keep pointing out that HANA is not addressing the hardware it runs on very well. So if you aren’t even addressing the hardware properly, why are we worried about SPs? Furthermore, SP’s bring up more portability overhead for different DBs. Also, if SP/CDSs are so effective, why won’t SAP publish any benchmarks on S/4HANA on ECC?

This gets into the topic if how most of SAP’s proposals, particularly since the introduction of HANA, where SAP took an abrupt turn from Netweaver as their primary marketing tentpole and transitioned to HANA, have been focused on making architecture arguments around performance. This is incongruous, as the performance was never an SAP selling point. Today the majority of SAP software performs worse in terms of speed and usability of that speed versus competing applications.

Previous points of emphasis on SAP were reliability and business process/functionality coverage. But first with Netweaver (which focused on integration) and then with HANA, SAP essentially changed its historical message and value proposition.

Oracle on SAP’s Code Push Down

In Oracle’s August 2019 paper Oracle for SAP Database Update, Oracle has the following to say on SAP’s innovation claim regarding code pushdown.

SAP used to think of a database as a dumb data store. Whenever a user wants to do something useful with the data, it must be transferred, because the intelligence sits in the SAP Application Server. The disadvantages of this approach are obvious: If the sum of 1 million values needs to be calculated and if those values represent money in different currencies, 1 million individual values are transferred from the database server to the application server – only to be thrown away after the calculation has been done. As a response to this insight, SAP developed the..

„Push down“ strategy: push down code that requires data-intensive computations from the application layer to the database layer. They developed a completely new programming model that allows ABAP code to (implicitly or explicitly) call procedures stored in the database. And they defined a library of standard procedures, called SAP NetWeaver Core Data Services (CDS).

20 years earlier, Oracle had already had the same idea and made the same decision. Since version 7 Oracle Database allows developers to create procedures and functions that can be stored and run within the database.(emphasis added) It was, therefore, possible to make CDS available for Oracle Database as well, and today SAP application developers can make use of it.

How can code pushdown be innovative if Oracle had been doing it 20 years before SAP?

Restricting Stored Procedures for Competitive Reasons

In fact, SAP restricting SPs of S/4HANA is the primary limitation to being able to port S/4HANA to AnyDB. SAP is allowing the CDSs to be ported, but not other SPs.

Code that was taken from the application layer in ECC and was pushed into the SPs used to belong to the customer when they purchased the ECC license. But with S/4HANA that code did not transition to the customer. were taken from the application layer in ECC and were pushed into the SPs used to belong to the customer when they purchased the ECC license. But with S/4HANA that code did not transition to the customer.

SAP has proposed that this is all new code, but it could not be. Else, how did ECC do these things before?

The question that no one seems to be asking is why SAP has control over code that was previously in the application layer but was migrated to the DB layer as a stored procedure. These are codes that SAP supposes to deliver for their customers who paid for their software. This is code that the customer should be able to use as they wish under the license. That is they should not be restricted by code that is in SPs that SAP controls how is run.

The Proposed Logic of the Importance of the Code Pushdown

Now let us switch from one type of code pushdown (SPs) back to another type of code pushdown (CDSs)

Let’s look at SAP’s logic for the CDSs. Here was a recent argument made in favor of CDSs.

Without CDS (labeled as “Classic Approach” in Figure 1), intensive calculations are done on the application layer avoiding costly computations in the database. This results in rather simple SQL queries between application and database layer. The drawback is however that lots of data need to be transferred back and forth between those two layers. Often, this is very time-consuming. “

Is it? With 2018 hardware? (or 2014 hardware as not all hardware is new).

What does SAP think its applications do? SAP does not compete in high-performance computing applications. These are not scientific applications, massively parallel scientific processing or even Big Data.

f there is a problem with transferring data between the two layers, then the entire application should be put in the database. Or most of it in the database. Is that such a good idea? We have software that performs much better than SAP on smaller hardware, and they do it with the standard division with application logic in the application layer and just storing data in the database.

SAP’s Arguments for CDSs

SAP has been communicating to customers that they should use HANA CDSs as a primary way to access SAP HANA data.  And that CDS views are the way SAP will go forward in the future, which are available through OData interface.

Our Analysis

  •  The OData interface is both problematic and not as flexible as SQL.
  • SAP should not be defining how you consume of view the data. SAP offers CDSs. Customers can use them or not use them depending upon whether they find they fit their needs.
  • Business logic cannot be published to the CDSs.

Advice on Enjoying the 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 needs to police its use of the term pushdown or it will cease to have any meaning.

The evidence is how HANA has so vastly underperformed its performance hype as is covered in the article HANA as a Mismatch for S/4HANA and ERP.

SAP is not actually focused on performance, it is using performance to push out other database vendors. What SAP cares about is using the idea of performance to push customers down the rat maze in a way that benefits SAP the most. SAP can use arguments about performance to make them accept that logic of the lack of S/4HANA portability to different databases because SAP’s help restricts that portability. That is at least to the laymen — if SAP wanted, they could share the S/4HANA SPs with Oracle, IBM, and Microsoft, and all of these companies would pay the cost of performing the porting of the SPs to their respective databases. But the do not want to do this. They want to block out other vendors and restrict choice. And they are doing it retroactively because of the previous versions of their ERP system was portable to different databases, and that was the assumption under which it was purchased.

Core Data Services is a mechanism of lock-in presented as a positive functionality for SAP customers. SAP calls them Core Data Services because they are trying to maintain the illusion that they are doing something very different and innovative from other database vendors. Normally this functionality is called as a stored procedure. Stored procedures are how Oracle increases the difficulty for companies in moving away from the Oracle database and how it reduces the portability between applications and databases.

But SAP still will not release the SPs because they don’t want S/4HANA ported, because they want to use S/4HANA as a wedge to get database sales that they would not otherwise get in an open competition. We cover SAP’s unwillingness to benchmark S/4HANA on HANA in the article The Hidden Issue with the SD HANA Benchmark.

SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos

Fact-Checking SAP’s HANA Information

This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.

SAP Video Accuracy Measurement

SAP's Statement
Brightwork Fact Check
Link to Analysis Article
HANA is a Platform
HANA is not a platform, it is a database.How to Deflect You Were Wrong About HANA
HANA runs more "in-memory" than other databases.
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
S/4HANA Simplifies the Data Model
HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.Does HANA Have a Simplified Data Model?
Databases that are not HANA are legacy.
There is zero basis for SAP to call all databases that are not HANA legacy.SAP Calling All Non-HANA DBs Legacy.
Aggregates should be removed and replaced with real time recalculation.
Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.Is Hasso Plattner Correct on Database Aggregates?
Reducing the number of tables reduces database complexity.
Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.Why Pressure SAP to Port S/4HANA to AnyDB?
HANA is 100% columnar tables.
HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.Why Pressure SAP to Port S/4HANA to AnyDB?
S/4HANA eliminates reconciliation.
S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.Does HANA Have a Simplified Data Model and Faster Reconciliation?
HANA outperforms all other databases.
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.

The Problem: A Lack of Fact-Checking of HANA

There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Inaccurate Messaging on HANA as Communicated in SAP Consulting Firm Videos

For those interested in the accuracy level of information communicated by consulting firms on HANA, see our analysis of the following video by IBM. SAP consulting firms are unreliable sources of information about SAP and primarily serve to simply repeat what SAP says, without any concern for accuracy. The lying in this video is brazen and shows that as a matter of normal course, the consulting firms are happy to provide false information around SAP.

SAP Video Accuracy Measurement

SAP's Statement
Brightwork Fact Check
Link to Analysis Article
HANA runs more "in-memory" than other databases.
HANA uses a lot of memory, but the entire database is not loaded into memory.How to Understand the In-Memory Myth
HANA is orders of magnitude faster than other databases.
Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.How to Understand the Mismatch Between HANA and S/4HANA and ECC.
HANA runs faster because it does not use disks like other databases.
Other databases also use SSDs in addition to disk.Why Did SAP Pivot the Explanation of HANA In Memory?
HANA holds "business data" and "UX data" and "mobile data" and "machine learning data" and "IoT data."
HANA is not a unifying database. HANA is only a database that supports a particular application, it is not for supporting data lakes.
SRM and CRM are part of S/4HANA.
SRM and CRM are not part of S/4HANA. They are separate and separately sold applications. SAP C/4HANA is not yet ready for sale. How Accurate Was Bluefin Solutions on C-4HANA?
Netweaver is critical as a platform and is related to HANA.
Netweaver is not relevant for this discussion. Secondly Netweaver is not an efficient environment from which to develop.
HANA works with Business Objects
It is very rare to even hear about HANA and Business Objects. There are few Buisness Objects implementations that use HANA.SAP Business Objects Rating
Leonardo is an important application on SAP accounts.
Leonardo is dead, therefore its discussion here is both misleading and irrelevant.Our 2019 Observation: SAP Leonardo is Dead
IBM Watson is an important application on SAP accounts.
Watson is dead, therefore its discussion here is both misleading and irrelevant.How IBM is Distracting from the Watson Failure to Sell More AI and Machine Learning
Digital Boardroom is an important application on SAP accounts.
SAP Digital Boardroom is another SAP item that has never been implemented many places.

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.

Search Our Other HANA Performance Content



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

The Suspicious Timing of SAP’s Flip Flop on Processing in the Database

Executive Summary

  • Relational databases are oversimplified by the ERD diagram.
  • Complexities in relational databases mean that they are often not fully leveraged by applications.
  • SAP targets low information buyers and provides a steady stream of inaccurate information around databases.

The graphic above is a detailed explanation of SAP’s internal process of how SAP determines what is true, and what technical viewpoints they will hold. 

Introduction: How Amazing Are Databases

This article began as a discussion with some colleagues around the question of how much the application leverages the capabilities of a modern relational database. I observed that while developing a new application and going through the data modeling process required a discussion of how the database would process the data that we stored, and therefore how that would be represented. Some of the things that were explained to me regarding what the relational database could do, and what we could take advantage of seemed like magic.

If you are like me and you spend most your time in flat files and configuring SAP applications its easy to forget how amazing databases are. Let us begin there.

Working in the SAP space is like being caught in a time capsule. And SAP does not leverage the capabilities of modern relational databases, all of their promotion about HANA does not change this.

Multi-Tenancy: The Foundational SaaS Functionality

For example, one of the amazing features of modern relational databases is multi-tenancy. However, how many SAP applications that were not acquisitions are multitenant? How much experience does SAP have, in its homegrown products, in multitenancy? Not S/4HANA, while marketed to the hilt, it S/4HANA in the cloud not only has hugely few customers, it will just be multi-tenant for “baby customers,” (as is covered in the article is S/HANA Designed for the Cloud).

There is a segment of people who understand databases at the right level and can leverage their capabilities for new application development. That is I am not talking about tuning an existing database or creating structures to support reporting; I am talking about building entirely new applications.

This is a minority of the overall market for database skill. Naturally, most the database work is for administrators, whose job it is primarily to maintain existing databases.

Do Relational Databases Work as an ERD Diagram?

No. A relational database is far more complicated than can be represented by ERD diagrams. Our touchstone concerning how relational databases work is the ERD diagram; the ERD diagramming does not do a good enough job of expressing what is going on in the DB itself.

ERD is just what we have today. It allows us to organize the tables and the fields and tables and the relationships in the data model. But it only captures a few dimensions of what the relational database does.

Are Modern Relational Databases Well Leveraged by Applications?

It occurred to me that there is some type of drop off between application sophistication and database sophistication. That is most of the applications that I have evaluated don’t leverage enough of the capabilities of the RDBMS. And here I am referring to an open source RDBMS, not Oracle, which has more functionality of course that what I am developing my application for.

Let me give one example of an application that does an excellent job of leveraging what the database to offer so you can see what I mean.

Oh did you want something out of SAP BW? Well, roll up a sleeve. On SAP projects working in SAP BW is a bit like getting your blood drawn. 

SAP came out with the idea of placing the BW on HANA to improve performance, but lost in the hoopla around HANA was that I had been using an application for years that was able to blow BW and DP (DP uses the same data workbench as BW) away in performance. I could load up as many attributes as I wanted, and create any hierarchy that I wanted. I was and am still able to perform forecast testing without any applying any of the complicated rules about data setup that are required in BW and DP. And my performance on a laptop was far higher than the company could attain with their more massive server.

Leveraging the Database

That is called leveraging the database. My hardware was tiny. My database was open source. It slew the performance and usability of SAP. SAP BW that I competed against was on Oracle. So no problem with the database. The problem is that SAP BW was unable to properly take advantage of Oracle. This must be well known within Oracle’s database development group, but SAP is quite poor at developing applications that leverage Oracle’s database. SAP’s primary product is still ERP, and ERP is not an unusually heavy performance application. ERP’s most intensive process is running MRP and DRP.

And let us get into that topic a bit as the details are important.

Is MRP Processing a Big Deal?

MRP was first developed to run on systems that were pre-hard disk. That is right; the first MRP systems ran on tape-based systems!

“For those that are old enough, remember the introductory sequence to the 1970s TV show the 6 Million Dollar Man, where there is a brief shot of a 1970s tape storage system in action.”

So MRP is not only a “pre-advanced database,” mathematical routine, it is a “pre random access” mathematical routine. And once again, I can run MRP faster on a laptop with a specialized application than huge companies can run MRP in SAP ECC.

So while David versus Goliath was a fable, it does exist in systems. And it exists when the designers of one “team” have an advantage over the designers of the other “team.” 

**DRP is a method similar to MRP, but less processing intensive as only stock transfers are created, and by that stage the production process is complete.

Most of the rest of what ERP systems to is transaction processing (updating that financial account, posting goods issue, bing bing bing — small database updates, all day long).

The modern ERP systems have its origins in banking systems. After the military, banks were the next major area to be computerized. And of course, when it comes to financial transactions, the movement of money into accounts must be 100% reliable. The focus on transaction processing is reliability, not performance.

How the Applications Beat SAP’s BW

This is because the application was so well written and knew how to leverage the database. SAP’s development team, with all of its resources, lacked the development capability of a small vendor with no more than five people working for them. CIO and ComputerWeekly don’t cover that kind of story — its bad for their funding. If you want coverage in the major IT media outlets, don’t forget to bring a big wad of cash. 

So that is just leveraging the MySQL or PostgreSQL.

It occurred to me if in the database community there is a discussion and sentiment that goes something like this……

Can you believe that that is all the application was able to leverage from what we have to offer?”

To this point, one of my colleagues responded…

“Yep. The programmers will only use what he knows. That’s why we make it transparent to the programmers. The DBA will analyze which tables should be in memory and do it.”

Being Misinformed by SAP

Concerning SAP, we are going through a period of excellent database miseducation courtesy of SAP. Much of what SAP says about databases is for competitive reasons and is not true.

“Oh, my database compresses.”
“Oh, I can run the database faster.”(“100,000 times faster” – Bill McDermott,

“People will work between 10 and 10,000 faster because of HANA” – Steve Lucas.)(turns out not to be true, but was database performance a problem for SAP’s customers before they introduced HANA?), as covered in What is the Actual HANA Performance?

This was the problem when a company placed profit maximization before communicating what is true. Furthermore, what SAP is telling companies to focus on concerning databases is just plain wrong.

“Simplified data models lead to simplified business processes.”(covered in Does SAP S/4HANA Actually Have a Simplified Data Model & Faster Financial Reconciliation?)

There is far more exciting stuff in databases to emphasize. For example, multitenant functionality is fascinating. And all manner of decisions, with trade-offs to be made.

HANA’s Multitenancy?

Why doesn’t SAP emphasize HANA’s multitenancy capabilities? Because no software vendor would be stupid enough to develop with HANA.

**Actually, that is a question customers of SAP should ask. If HANA is so great, if HANA’s performance is so amazing, if its TCO is so low (lower than MySQL even?, so low that SAP pays you to use it?) why can’t you find software vendors that use HANA to develop anything? (Hint, to SAP customers, software vendors know more about software development than you do.)

How SAP Customizes its Messaging for Low Information Buyers

Let us face facts, HANA is for low information buyers, which means buyers that don’t work in software and which can be coerced and tricked into buying their database through their allegiance to SAP through career reasons, etc. That is those companies that allow themselves to be victimized……excuse me, I mean to write, “take guidance” from Deloitte or Accenture.

The upshot being, SAP does not emphasize multitenancy as multitenancy is functionality for software vendors. SAP can’t make money on the functionality, so who cares. One might expect an article on SAP as to why multitenancy is completely overrated.

So Much False Information Being Spread

And the problem with having SAP spread so much false information about databases is that most of the people that repeat what SAP says have no idea if it is true. Many are..

  • Just looking for a good job with health insurance, and they don’t rock the boat. They have families and do not have time to research things for themselves.
  • Many will work in sales, who’s only real job requirement regarding information, is to relay what SAP says. If they don’t, they are in dereliction of their duty.
  • Deloitte and Accenture are consulting arms of SAP, and repeat what they say. They don’t care if it is true but has determined it is profit maximizing to do so (see the case study of how the major SAP consulting companies humiliated themselves lending their support for SAP’s ludicrous Run Simple campaign as we covered in the article Is SAP’s Running Simple Real?
  • The IT media system employes mostly journalists with no technical background, and no editorial leeway to question what SAP says (SAP is the customer of IT media, the reader is the audience and increasingly contributes nothing financially to the content development process.)

Therefore, the entire system is based on the elite opinion which is created by SAP, and then it is unthinkingly propagated throughout that system. These entities that what SAP says is true. Therefore, what SAP says is true, forms the basis of what is true for a large number of people and organizations.

Should One Process in the Application or the Database?

During this discussion, another colleague brought up the following point.

“Just an anecdote: at the beginning of this millennium I worked in an PL/SQL Oracle project. The whole business logic in PL/SQL stored procedures. Some UI logic in Oracle Forms. Our leading company SAP ABAP architect told us that letting the database do the job is a bad idea. Let the powerful highly scalable application server do the work for you. Load the database table records into an internal ABAP table, sort, sum, do work, etc. and write the result back to the database. Now SAP has its “Code Pushdown” and sells it like their “innovation” that business logic is (partly – when needed) running in the database layer. Great to know that I was working with 2017 bleeding edge technology 15 years ago.”

I thought this was a great anecdote.

Getting A Real Understanding of How SAP Formulates Technical Opinions

SAP does not make decisions based upon technical reasons. So if they have all applications and no DB, then their “technical” opinion is that the application should do the work, and the DB just a container for data. But then when they develop a DB, and they can use the DB for marketing reasons, and if by using stored procedures they have an excuse not to port to other DBs, then they are in favor of doing the work in the DB!

SAP’s Flip Flop on Advanced Planning Systems

I witness this same flip-flop in that late 1990s. At that time I was working for a supply chain planning vendor.

SAP’s position was that all supply chain planning should be done in its ERP system. Then SAP developed APO. And at that exact point, SAP began to extoll the virtues of performing planning outside of ERP.

Its all about “what is good for us,” and has zero to do with what is true technically!

The present economic theory holds that technical accuracy is a distant second to profit maximization. This means that the technology must follow profit maximization, and to not do so is a great insult to shareholders. And according to the US court system, there lying in commercial settings is not lying, it is “puffery,” as explained in court decision of San Marin County versus Deloitte.

Additionally, the promotion of what is true over what is profit maximizing will cause Tinkerbell’s light to go out.

Advice on Enjoying the 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.



It is complicated to learn something from an entity that is completely lacking any integrity, and merely intent on pushing you down a path that makes them money.

This is what taking information from SAP is like.

One must listen with extreme skepticism and verify every statement, particularly given SAP’s track record for accuracy, which we have evaluated in the article A Study into SAP’s Accuracy.

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.

Search Our Other HANA Performance Content