Skip to Content
Author's profile photo Joseph Caruso

Is anyone still planning to deploy BW-on-HANA via Scale-Out?

Scale-out or Scale-up – that is the question!  I’m preparing for my SAPPHIRE/ASUG session (A4526: Scale-up Architecture Makes Deploying SAP HANA Simple) and I’m trying to get a sense for what new HANA implementations are planning when it comes to hardware infrastructure.

With a fear of showing my age, I want to draw a comparison to a time when scale-out data centers were so common that the term scale-out wasn’t used because it was considered normal.  Last night’s episode of Silicon Valley (the data center scene for you SV fans) made me think back to my early days as an MVS systems programmer – we outgrew our data center and had to build a new one with several times the square footage as the original.  While it seemed like a great idea at the time, Moores Law and improvements in software reduced the required hardware footprint by so much that we ended up with enough unoccupied raised-floor space to accommodate a Coldplay concert! 

Throughout the years, multi-node solutions have been replaced with single node equivalents – back in the day, large SAP deployments were based on multi-node relational databases because of capacity requirements.  We wouldn’t even consider doing this today (with a few exceptions).

By now, I’m sure you can see that it is my opinion that only the absolute biggest BW systems (greater than 16TB of HANA memory) require the scale-out model.  I’m surprised when I read forums and blogs where customers describe their up-coming scale-out deployments.  I believe that the scale-out approach adds a significant amount of complexity while providing only minor benefits.  With that said, I’m sure that some of you disagree with my opinion and have thoughtful reasons as to why you prefer a scale-out approach.

Please comment as you see fit and stop by my session on Thursday at 2PM so we can compare notes.


Joe Caruso

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi Joe

      Great conversation starter!! We are indeed using scale-out and we are not even 1TB. The reason for this is because we are deploying BW on HANA on AWS and anything > 256GB is not yet available, That is why you might find a large no of people using scale-out

      Author's profile photo Tommy Baunwall
      Tommy Baunwall

      We are running a 17TB HANA for BW in production - so we do not even have the choice of using a scale-up system. 😀

      Author's profile photo Jay Roble
      Jay Roble

      We are migrating 2 BW's on Oracle (~12TB & ~7TB) to HANA MCD (Multitenant Database containers i.e. 2 DBs, 2 BWs) to a HANA TDI HP 10 TB (9+1 1TB nodes).

      We did have an issue, that the HANA MCD can NOT support BW's with different time zones, both must match the HANA OS time zone. So as a pre-migration step, we had to convert both BW's to the same UTC time zone. (there were a few ABAP's that needed to be changed).

      Author's profile photo Marc Bernard
      Marc Bernard

      Hi Joe,

      based on our sizing guidelines for BW, you could use only about 7.0 TB of the 16 TB server for storing customer data. That's good for many customers but might still limit future data volume growth. I get you point, but for the next couple years, I don't see us going away from scale-out landscape for BW (but we will continue to simplify the administration of such landscapes 🙂 ).

      Product Management SAP HANA DW

      Author's profile photo Heiko Küst
      Heiko Küst

      Hi Joe,

      as far as i know only 4TB HANA nodes are supported at max for BWoH. Beyond that you have to scale-out.

      Do you have other information?

      Best Regards


      Author's profile photo Ashish Bhinde
      Ashish Bhinde

      Hi Joe

      We are currently migrating our 30TB data into 4TB on HANA machine using scale out option, we have two nodes of 2TB each with High Availability option enabled.

      Following factors were driving us for this option:

      1) Flexibility in Scale down when the data volume is reduced with the implementation of NLS.

      2) Our Hardware vendor was highly inexperienced in providing service/support for single 4TB node.

      3) High flexibility during maintenance of nodes.