Skip to Content

SAP on HANA, and Pushdown for All: News about ABAP’s Adventurous Relationship with the Database

You may have heard about the January 10 news conference, in which SAP announced the availability of the Business Suite on HANA. Along with some fellow SAP Mentors, I was given the chance to attend this event in the Frankfurt/Main location, and while “Business Suite on HANA” per se wasn’t new to me, other information from the event was extremely new and noteworthy to me.


Fig. 1: SAP Mentors at the “SAP on HANA” press conference: Luke Marson, Matthias Steiner, Mark Chalfen, Thorsten Franz, Peter Langner, Tobias Trapp (photo by Martin Gillet)

A change in the ABAP programming model going beyond what has been previously discussed

To sum it up briefly, in previous years, all ABAP programming against the database used a layer of abstraction that reduced the possibilities to the smallest common denominator – a very small subset of SQL features defined by those functions that were supported by all databases on which SAP runs.

Then came the plan to run the Business Suite on HANA. When you run existing operational ABAP applications on HANA, the result is sometimes disappointing, and large parts of the applications don’t run any faster than they do on other databases. The reason is, simply put, that traditional ABAP applications won’t let HANA do what it does best: The things HANA is best at are traditionally either simply not done in ABAP applications (e.g. mass queries instead of SELECT SINGLE), or the ABAP application logic handles them itself instead of leaving them to the database (e.g.  calculations, complex joins and transformations of datasets).

Enter code pushdown and HANA-specific code

In order to achieve the amazing performance HANA is capable of – executing queries and calculations hundreds or even thousands of times faster than other databases –, one has to  change the applications so that they let the database do the things it can perform much faster than the ABAP application server. This means that a portion of the application code must bypass the abstraction layer and be written natively and specifically for HANA. (For a better understanding of code pushdown, please read Eric Westenberger‘s excellent post, SAP TechEd 2012 – ABAP for SAP HANA: the database is not a black box anymore.)

You might ask: “Okay, so native SQL exploiting specific features of database platforms and stored procedures run faster than traditional ABAP applications, which involve several more physical, logical, and abstraction layers – big deal. We knew this before HANA. Why didn’t we use stored procedures and native SQL to optimize ABAP applications for, say, DB/2 or Oracle?”

The canonical (politically correct) answer would be: For traditional database systems, the performance gains that could be gained with such an approach exist but are outweighed by the loss of compatibility. In other words, it’s better to have an application that runs at 80% of its optimal speed but on all databases supported by SAP than to have an application that runs 1/4 faster but only on one database platform. This argument works as long as the delta between native and database-specific is not too big. We wouldn’t lightheartedly give up portability and simplicity for marginal performance gains, but if we’re talking factors of 100 or even 1,000, the business value might be so drastically increased that it’s worth giving up the abstraction against the database platform.

Gradually giving up abstraction

Logically, there are three stages of giving up abstraction against the database platform in the SAP Business Suite:

  1. Introducing optimizations that work for all database platforms or are at least performance-neutral: SELECT SUM( … )
  2. Using native features for HANA but not for other database systems
  3. Using native features for HANA and the corresponding native features for other database systems

To fork or to rewrite?

When optimizing existing Business Suite code to run faster on HANA, you’ve got two options:

  1. Fork for HANA
    For every optimization, introduce a fork (IF HANA … THEN … ELSE … ENDIF). The existing code remains unchanged, and new, incompatible code using HANA-specific artifacts, is added as the HANA branch of the fork. There’s a lot of value in the approach: It is the least disruptive for existing installations that don’t migrate to HANA, because if the part of the code they run is not rewritten, there is no danger of introducing new bugs, and any existing modifications or enhancements will continue to work like before. The new code that is processed in the HANA case can be radically optimized for HANA, no holds barred. The downside: redundant business logic, increased complexity, more testing required, all resulting in higher maintenance costs and loss of agility.
  2. Rewrite for all
    For as many optimizations as possible, try to get away without a fork. Rewrite the code once, so that the new code is processed on systems with HANA and without HANA. This can be done wherever there is a way to rewrite the code so that it performs with at least the same speed on traditional database systems, and significantly faster on HANA. This approach has the advantage that the resulting codebase is simpler and with less redundancy, resulting in easier and cheaper maintenance and better agility. The downside is that is goes only so far in exploiting the advantages of HANA, still leaving much to be desired, and is more disruptive in the shortterm.

The smart solution is to combine the two approaches: Realize as much of the HANA optimization as possible with the “rewrite for all” approach, but don’t be shy to use “fork for HANA” when amazing factors or entirely new features are within reach. Each individual design consideration should be impacted by the value of the particular enhancement (how frequently does it run, and what benefit can be gained by making it run faster) and by the disruption it causes (how likely it is that the code to be replaced or forked has been modified, enhanced, or duplicated by customers, and how harmful is the respective decision to replace or fork to those enhancements). 

Two measures for HANA and other databases?

With these paradigm changes, there is one thing I found slightly political, or architecturally inconsequent: If we concede that code pushdown to the database makes sense when it creates drastic improvements and new opportunities in the HANA case, then why should the same approach be per se bad for other database systems?

Of course I can see why HANA is special to SAP and doesn’t receive the same treatment by the Business Suite as other database systems. A certain extent of what might be called favoritism in a half-jesting fashion is acceptable here, but it would be difficult to follow if SAP were to pragmatically overthrow the previously existing architecture axiom of database-agnosticism for their own database only but keep it firmly in place for the databases of all other vendors. 

In some cases, the same stored procedures or native SQL code accelerating the Business Suite on HANA might run perfectly on other database platforms, or could be ported with minimum effort and achieve significant performance improvements there, too. If the improved performance is worth the redundancy in the code base (with all its implications for maintainability, error-proneness, and so on), then it might be justifiable to pursue this venue even for databases other than HANA.

Please note that this is two big steps away from the previous paradigm of database-agnostic ABAP applications. Having said that, please note also that exceptions have been made in the past, for example in SAP Business Warehouse, whose code is full of forks for specific database platforms.

And pushdown for all

Considering this, I was fascinated when – I think – Sam Yen after demoing MRP on HANA explained that Stored Procedures would now be a used for HANA and other databases, too. This means that the new (revived) architecture paradigm of code pushdown – the ABAP application server giving some of the work it has traditionally considered its own to the database – won’t be limited to the HANA case.

I don’t remember the exact wording, but I found two blog posts whose authors confirm my understanding.

Siva Darivemula writes in his excellent recap blog post, Real-time Business Processes powered by SAP HANA:

“Using SQL Stored Procedures (note: as I understand it), a single version of Business Suite can work with all major databases such as Oracle, IBM DB2, SQL Server, Sybase ASE, etc. in addition to SAP HANA database. This is great news for current customers that have significant investments in their database infrastructure.”

I even have a second, more prominent witness: Vishal Sikka writes in his post, A Promise Delivered – SAP Business Suite Is Now Powered by HANA:

“Moreover, thanks to the power and universality of SQL, SAP Business Suite remains open to other database technologies and vendors and only one version of SAP Business Suite goes forward without disruption. Innovations in the SAP Business Suite, such as push down of data centric processing logic from the application server to database tier via stored procedures would be made available to other databases too making them perform better too.

I might dwell more extensively in a later installment of this blog on what this means for ABAP application development: less schizophrenia at the ABAP level, but a harder struggle to deal with the peculiarities of various database platforms at the native level. For now, let it just be noted that this a great step towards pragmatic architecting, and I look forward to the fruits of SAP’s cooperation with database vendors on a tighter database integration and better compatibility. After all, the broader the shared base of compatible functionality between the databases under an ABAP server, the better for all involved. In a way, it’s as if SAP were aiming for a drastic expansion of the speed and functional richness of OpenSQL, and perhaps this is indeed where we will end up.

The road ahead

There’s room for speculation about the implications of these news, and more will be known in the future. For now, it seems safe to say that the previously bipolar HANA/non-HANA model transforms into a spectrum where, instead of being limited to the lowest common denominator, we can now exploit the different sets of native capabilities of various database platforms if we so desire: 

  • Power of HANA: Thanks to the Calculcation Engine, SQLscript, and many other features of HANA such as its built-in Predictive Analytics capabilities, the power of HANA goes way beyond the power of SQL, and the Business Suite’s applications designers will use those features to help HANA customers get the most out of the platform. (Works on HANA only.)
  • Power of SQL: More or less compatible or portable SQL Stored Procedures or native SQL going beyond the power of OpenSQL are another option. (Works on some but not all supported databases.)
  • Power of ABAP: And there’s of course good old OpenSQL.  (Works on all databases supported by SAP.)

I can’t wait to explore what’s coming, and to continue to contribute the conversation. Let’s keep each other posted.

You must be Logged on to comment or reply to a post.
  • Always awesome, Thorsten

    Part of me wants to know the business value of all this?  Does this mean if I am using FI-CA then I can post real-time to the general ledger and see all my receivables and revenues (this is not the case today)

    Real-time SAP settlement too?

    Of course I can’t wait to hear/see more of your experiences – I did like Tobias Trapp’s blog about the new FBL9 (account balance display)

    I don’t think it will ever be boring at SAP.


    • Tammy.

      I don’t know when it will happen, but I’d say your ideas are completely consistent with Vishal Sikka‘s declaration of the “End of Batch”. So yes, this is where SAP sees the Business Suite going, but I suppose it will take a lot of time to rewrite the code, and as I said earlier, the disruption caused to customers whenever a line of old SAP code is touched must be taken into account…


      • Hasso was very clear – this is the beginning of the end for batch and ABAPers will find they have much less to do. The first thing ABAPers should do (as per Thomas Jung) is learn or brush up on SQL.

        Net-net: implementations in existing landscapes should be relatively straightforward, even with significant customizations. According to Appleby, the more an implementation has been customized, the easier ti will be to HANA-ize. The reason given is that those jobs tend to include a lot of poor quality code which can be cleaned up/out.

        But…I’d encourage folk to get out of the weeds and get into the sunshine – start thinking about the NEW apps that can be built where there is serious value rather than refactoring for something that is not yet complete.

        That’s because this is only a stepping stone to SAP offering BusinessSuite on HANA in the cloud…at some point in the not too distant future. (cough)

  • You have such excellent explainability, Thorsten! Thanks for sorting it all out.  Obviously, I might just have to dust off some SQL books…  but clearly I’d need more sessions next to you just to keep up at quarter-speed. 

    • Moya,

      With the variety of SQL dialects around, the question for me was, which SQL books to dust off or buy? I ended up buying some books, but every HANA question I had in real life was answered by Google, with the answer being either in an SCN or forum, the online documentation or reference, or – occasionaly – a tutorial about non-HANA databases…

      Thanks for the kind words about sorting it out. They’ve made me happy, because trying to sort things out and provide clarity is at the core of what I am, or try to be. 🙂  



      • Just curious which online documentation/reference you refer to — at Would love to see where the info is that you find most valuable (aside from — that i already know 🙂 )

        • Moya,

          The single most valuable source of documentation I use is the “SAP HANA Developer Guide” at – it has screenshots, code samples, and explanations, which are rarely found together in one document. 🙂

          Other than having that open in the browser at all times, I use Google for searches, which usually brings up forum posts and the occasional blog post from SCN and



          • Fantastic – thanks so much for pointing me to that piece.  I’m going to search for the team who wrote that internally — if it’s something *you* find helpful, we all should be able to benefit from their tips.

            A couple of minor nits regarding code samples in docs — i noticed 1) the PDF doesn’t allow you to copy text – does that make it hard to repurpose the code samples? and 2) the code samples aren’t color/formatting-highlighted — would they be improved if they were?

  • Hi Thorsten,

    we seem to be on similar wave lengths at the moment as I was thinking about this over the weekend and considering a similar blog.

    I have also been thinking a bit about the new ABAP statement “CALL DATABASE PROCEDURE” that will be coming in NetWeaver 7.4.

    This will make it very easy for the ABAPer to call a database procedure – but I wonder how the actual implementation will work and if (and how) the existing software logistics features of the ABAP stack will support it.

    For example, will the database procedure be defined in the ABAP workbench and therefore exist as both an ABAP artefact as well as a database artefact – in the same way that other database artefacts do?

    If so this would provide the same design-time and runtime features we know and love about the ABAP environment as well as the benefits af being able to package up and transport all development artefacts through the dev-test-prod landscape in the same way we have always done.

    But the downside is that this means we must either “Fork for HANA” around this call or build a separate stored procedure implementation for every possible database platform – or at least a fallback procedure for non-HANA databases. That would, I think, be a very new type of ABAP DB artefact – one that has a single interface but multiple implementations.

    Alternatively the stored procedures could just be defined at the database level. This means that the ABAP design-time will need to introspect these procedures to perform even rudimentary syntax checking and that an alternative method (or at least additional step) for transporting these database artefacts will need to be performed. CTS+ would have a role to play here I guess.


    Graham Robbo

    • Graham,

      Similar wave lengths indeed, it’s also true for the points you raise. 🙂

      • Regarding calling database procedures: There’s a degree of design-time integration when ABAP in Eclipse and HANA Studio (also a set of perspectives in Eclipse) run in one Eclipse and are at least loosely integrated.
      • For the transport system, I expect both CTS+ and CTS will be options for relevant HANA artifacts. In the case of ABAP on HANA applications, CTS will be the preferred option. (Just my hunch.)
      • As far as design-time checks are concerned, for example to check the typing of parameters, that is typically an area where SAP publishes a first release that leaves some features to be desired but catches up quickly. Again, that’s just my hunch taking into account the importance of going to market quickly, the presumed priorities of the required features, and whatever was demoed at TechEd 2012.

      We live in exciting times, and the new SAP listens. Excellent folks like Thorsten Schneider spend their working days, evenings, and nights gathering our feedback and feeding it back into development.



  • Thorsten,

    great tip on forking and how it has its origins in BW. rewrite seems to be the ultimate goal of any developer worth its salt. having patent application in mind will not hurt either.



    • I agree, Greg. As far as patent applications are concerned, Tobias Trapp figured it all out and showed me that reading SAP’s patents in online patent databases can be very well worth your time: Sometimes, it replaces or complements incomplete documentations; sometimes, it provides valuable pointers where SAP might be going in future releases; and sometimes it’s just fun and educational. 🙂



  • Hi Thorsten,

    Thanks for great blog. When I began with SAP, I was amazed with one thing: Performance, Scalability in terms of the number of users and the level of concurrency. And I believed based on my own experience and from reading notes/blogs/SAP documentation that it was due to:

    1. Asynchronous updates using VB* tables
    2. Buffers (Number range, table buffering etc)
    3. SAP’s own handling of locks(Enqueue server) in combination with asynchronous updates.

    I would love to know your thoughts on new code’s impact on concurrency and scalability – may be too early to speculate – while using other relational databases(HANA uses insert-only architecture & if I remember correctly, no locking is involved except during delta merge which is handled asynchronously.)

    Best regards,


    • Bala,

      We seem to also be tuned to similar wavelengths… I’ve had some thoughts on locking, asynchronous updates, and buffers and the impact of HANA on that cooking in my head for a while and hope to get them out of the door sometime soon. For now, all I can say is that it requires careful consideration if you care about data consistency. 😉

      Thanks for your comment!



  • Hi Thorsten,

    Really a very good post…Even, when I attended the SAP TechEd in Bangalore in November, I realized that unless the code pushdown happens, it is not going to bring in paradigm improvement in performance.

    As an ABAP developer, just want to know if the ABAP developers will now need to also learn database specific SQLs in order to enable them to write the SPs or just like administrators (Basis & DB), we will now have 2 different skills (ABAP Developers and DB specific developers).

    It would be nice if I can hear thoughts from you as well as other community members.

    Best Regards,


    • Amit,

      Thanks for your comment. Yes, I believe that among the many new skills ABAP developers should acquire now, SQL and HANA’s SQLscript are among the first, followed by Java, XML, JavaScript, and HTML5 – in no particular order, depending on if you care about UI development, mobile, integration, or edge innovation.



      • Thanks for your response Thorsten…I have another question…Eventually (I can not really imagine any specific timeframe here, but,) if we are going to push down bulk of the processing to the database layer, I am just wondering if we would be again moving back to kind of 2 tier architecture?? Because as per my understabding, role of application server in this scenraio would be just to coordinate between UI & DB. Am I missing something here?

        Best Regards,


  • Hi Thorsten,

    Typically excellent and very detailed. My interpretation of what Hasso said was they would use a combination of both approaches, but it’s really hard to tell at this stage what they will do for sure. However, it is important because while SAP might optimize for HANA they might inadvertently optimize for other database technologies and this in-turn might lead to less of a need to move to SAP on HANA. I’m less of a techy these days, but no-one can underestimate the potential that the type of architectural changes are going to have on SAP development, maintenance, performance, and stability going forward.

    Best regards,


    • Luke,

      I agree. I think they displayed some greatness by admitting native SQL in order to accelerate Business Suite on non-HANA databases, which decreases the relative attractiveness of HANA but shows a credible commitment to those customers who do not (yet) adopt HANA.



      • Hi Thorsten,

        I feel part of the reason to support 3rd party DBs is just to stop annoying customers who don’t want to upgrade to HANA. I’m not so sure it’s about commitment 😉

        Best regards,


        • I agree. It’s,imo, not easy to support traditional databases using “SAP HANA only Software development environment at SAP”. It also doesn’t make sense from $$$/Euro standpoint. This support will cost both money and time for everyone, SAP, DB vendors & customer. The customers would feel the pain – even assuming new code works for the traditional databases – because they need to move the processing power(memory & CPU) from “application servers to the database server”. Then there is a limit on how much more memory & CPU you can add to one server.

          Best regards,


  • Hi Thorsten,

    very well written and informative – and a grain of great vision. It would be cool if SAP will unify the stored procedure dialects PL/SQL (Oracle) / SQL PL (IBM DB2) / SQL scripts (SAP HANA) of the world, but is it realistic?

    Interesting detail: To ease Oracle customers a migration towards DB2, IBM supports Oracle’s PL/SQL – at least a subset – running as stored procedures inside DB2 (google “DB2 oracle compatibility”) 🙂 Unequitably, Oracle by now allows IBM to implement Oracle’s PL/SQL but blamed SAP that their SQL script syntax was too close to Oracle PL/SQL. 🙁 A standardized stored procedure language is ot of sight.

    And whatever is going on in SQL script, what will it have to do with ABAP except a “CALL STORED PROCEDURE” statement (= level of integration in – say – every Java App Server)? Database developers, yours is the future!

    IMHO it would be great to see SAP and ABAPers adapt other obvious features of all decent up-to-date database systems. The ABAP applicaton server assumes a least denominator of database features that is at least 10 years old. Why use programmatic read locks of an application server to avoid dirty reads? Even DB2 supports isolation level “read committed”. Why not push down locking away from an enqueue server into the database (“SELECT FOR UPDATE”) wherever real tables are involved?

    Best regards


  • I’m eager to see how traditional ABAP developers will make use of SQL and stored procedures. Refreshing your SQL skills is easy to say, but if the ABAP dev is used to do a simple select * for years? And with SQL you can still do some weird and slow stuff. Inefficient SQL can still slow down a system designed to be fast like HANA. Specially that the need to optimize is gone: HANA makes bad and slow code look fast (not necessarily good).

    Knowing and understanding SQL is an art few master. I am not one of those, as I use hibernate (Java) and I will be surprised if 0.1% of ABAP devs “know” SQL.

    Will be interesting to see how native SQL on HANA / ABAP will be used.

    • Thorsten,

        Another piece of excellent writing.


        Given the (possible) speed differentials between the row based DBMS (Oracle, DB2/6, SQL Server) and HANA, I think it will be harder than ever for developers to hide poor performance behind the smoke screen of database performance. This is because small things (like changing SELECT * WHERE DELDATE = TODAY{} to SELECT VENDOR WHERE DELDATE = TODAY{}) will have a massive impact on performance. This applies as much to poor coding in general as it does to poor SQL. Having said that, there is the opportunity some automated tuning for SQL, along the lines of comparing what is used in the code against what is selected.


  • Just hope you keep HANA in the ABAP way of doing things (tight integration, developer tools on the server, etc) instead of the Java way (Eclipse, bad versioning, worse transport mechanisms).

    I’m not scared of SQL since I work with lots of different technologies but SAP Java has left me traumatized (it’s bad, very bad) and has made me a skeptic of all new approaches. 

    That said, I’ve got no clue how SAP is going to migrate all ECC to HANA compliant. Lots of legacy code with little to no encapsulation. Good luck.

  • Hi Thorsten

    Thanks for sharing this excellent blog with the community. I have few questions:

    1. If SAP Business suite is made tailored to SAP HANA then wouldnt it become dependant on SAP HANA database?? if yes the very purpose of database independent would be defeated.

    2. When you say SAP extends the stored procedures to all the database( not only HANA ) do you meant SAP is extending the Open SQL to include stored procedure commands or ABAP programmers should learn the stored procedures of all the database systems??


    Abdul Hakim

  • Thorsten,

    do I remember correctly that SAP will have a dynamic way of calling the appropriate code based on the DB for the given connection? So while you effectively fork the code I hope it’s not going to end up with ugly if/switch statements all over the code. Do you have any insight on SAP’s plans?