SAP HANA has garnered a great deal of attention in recent weeks and months. For an overview of the technology and its potential, please check my recent blog on the subject, “The real (potential) impact of SAP HANA.”
Since that blog was written, there has been a great deal of news in the SAP HANA world, and the surrounding cosmos as well. Rather than write another long blog on this topic, here is a list of some highlights:
- The pricing of SAP HANA is getting clearer. A low end (128GB to 256GB RAM) SAP HANA appliance could start at around $80K-$100K for the hardware. A few sources inside and outside the company (not under NDA) also indicated to me that the price of SAP HANA software is around $120K at the low end, stretching up to $1M to $2M at the high end. SAP says the pricing is not discountable, but early customers have told me that (at least for them), everything is negotiable. This puts the entry-level SAP HANA pricing at around $250K plus services. A pilot project could be done for less than $300K, with potential for very large business benefits. How hard is it to find a business analytics problem that is worth $300K if it can be completed 10x faster? For many businesses, there is no shortage of such analytics problems, and in some cases SAP HANA will actually perform 100x faster – or even better.
-
Pricing for higher end SAP HANA boxes is not as clear. If your data can fit into 1TB of RAM, then these single-system boxes should be OK for you. But how will you know if your data can fit into that memory size? It seems (and I would welcome a knowledgeable person’s correction on this if inaccurate) that SAP HANA can’t be used when data can’t fit entirely into one system’s memory, which currently tops out at 2TB (and at much higher pricing – an additional $250K or so, from those few vendors offering that high-end configuration).
- How much data can fit on any SAP HANA configuration? From discussions with a number of current SAP HANA users, this is not always clear, and SAP has some work to do to deliver good sizing tools. On average, users I spoke with report compression ratios of between 4 and 10 times for data – that is, if the data would take up 400GB in an ASCII file, the same data with HANA’s columnar compression would take between 40GB and 100GB in SAP HANA (your mileage may vary). Of course, the operating system and other software needs some memory to run, but this size of data should fit fine onto the smallest SAP HANA appliances. In a disk-resident database, you might need dramatically more disk space for such a data warehouse, since space will not be used efficiently (sparse data) and since the indices may take a significant amount of space – even more than the data sometimes!
-
How about this for a sizing tool – load all your data on a removable hard drive (ENCRYPTED!!!), and bring it to IBM, HP, Cisco, Fujitsu, Dell, and anyone else offering a SAP HANA appliance. Have them load it up for you on their hardware, and test out your queries. If everything is as simple as some customers and integrators have been telling me (which is pretty close to how simple SAP has been saying it will be), then the hardware partners should be willing to do a pilot like this for free. You’ll know exactly how much hardware you’ll need, and you’ll have a very good idea of its performance!
- As a killer new application, SAP HANA will be certified in November for running SAP BW. All BW reports, extractors, etc., should all run without changes (except MUCH FASTER) on SAP HANA after this release. Let’s face it – the overwhelming majority of SAP BW data warehouses are running on Oracle databases. If you have an Oracle database license priced in the range of $800K (and many medium-sized data warehouses are on such licenses), with a 25% annual maintenance fee, you are talking about $200K per year just for the database maintenance. If you could migrate that database over to SAP HANA, you might find that you paid for it in the first year by dropping your Oracle maintenance, and at the same time you may be delivering ten times more users or ten times faster results on reports and analyses. It wouldn’t be hard to imagine many Oracle databases being converted over to SAP HANA in the coming year – especially those running under SAP BW (and Business Objects soon too!).
-
SAP recently also discussed several analytical applications that will be made available on SAP HANA. These are interesting, but not where the short-term value will be for most customers – this will be SAP BW or Business Objects running on SAP HANA, and ultimately the rest of the SAP Business Suite running on SAP HANA. Or Sybase, for that matter.
- Oracle may be feeling some heat from SAP HANA – Oracle just introduced a low end database appliance offering, with hardware and software bundled for between $100K and $300K. While it is unlikely that this appliance would be able to deliver comparable performance to SAP HANA for those applications most suited to HANA’s current capabilities, this appliance would have broader application – for example, being currently suited to running production transactional applications such as SAP.
-
At the high end, a SAP HANA appliance might cost on the order of $1M for hardware and $1M for software. An Oracle Exadata data warehouse solution might cost 10x that number, delivering slower performance, consuming a lot more energy, and taking a lot more space.
- SAP has expanded the mechanisms for loading SAP HANA. You can now use log-based replication (replaying the logs on another database to copy it), and trigger-based replication (having a system notify SAP HANA when data is changed), as well as the previously available ETL-based replication (using BW extractors or other technology to copy data out in bulk/batch). The trigger-based replication mechanism is particularly interesting, because it updates the “data warehouse” (can you even call it that anymore with technology like this?!?) continuously, in near real-time. In addition, the trigger-based replication approach allows for consolidating data from several databases quickly and easily into a single data warehouse. If you have one database for your CRM system and another for your financials, both databases can propagate their updates into a single SAP HANA system for consolidated reporting and analytics. Trigger-based replication supports many-sources-to-many-targets replication.
- Business Objects metadata integration with SAP HANA metadata was not announced at SAP TechEd in Las Vegas, but perhaps will be available soon. Business Objects Explorer can run today on top of SAP HANA, which gives some level of integration that will benefit many SAP customers running SAP Business Objects. The more integration at the metadata level, however, the more appealing SAP HANA will become to Business Objects customers not running SAP systems.
Conclusions:
- SAP HANA is getting to the point where any customer running SAP analytics (especially SAP NetWeaver Business Warehouse aka BW) should be starting or at least planning an evaluation.
- SAP HANA will make its biggest impact – for customers – initially as an “accelerator” for SAP BW.
- SAP HANA may pay for itself in reduced database maintenance payments …
- … thus its biggest impact – for vendors – in creating pricing pressure on Oracle RDBMS for data warehouse instances.
- We may be still a long way from seeing SAP HANA replace Oracle, IBM DB2, or Microsoft SQL Server as the transactional data manager for SAP Business Suite.
For more on the strategic impact of SAP HANA, please see https://enterpriseirregulars.com/39209/the-real-potential-impact-of-sap-hana/.
Disclosures:
I worked for SAP for six years, including the period when SAP originally acquired the technology at the heart of HANA. SAP is a client as of the time of this writing.
Great blog as always, Dennis.
Just a few comments
1. At the moment, the only scale out solution is the one IBM offers as I understand (I work there). It is not clear if any of the POCs SAP did for customers have a scale out scenario. We are not really talking big data with HANA yet – as in petabytes.
2. Not sure if ORCL feels any heat from HANA yet, or if they will any time soon either. For one – HANA needs to mature as a DB for BW, and that needs time. And even if all technical stuff gets sorted out, it may be very difficult to get out of ORCL licenses without financial implications that make such a move unattractive.
3. ORCL, DB2 etc have a head start on the DB game, and it is not easy for a hither to non Db company to catchup. SAP has some very smart people leading the charge, so it is not impossible – but still quite an uphill task. ORCL will not sit around doing nothing. If ORCL does come up with a competing technology to HANA, it will make SAP’s life quite difficult.
4. Even if SAP displaces ORCL from 25% of BW instal base – it is a very small number. BW only has 16000 installations or something the world over. Will losing 4000 of that make ORCL feel any pain?
5. I think once HANA can go as DB for business suite – there is a potential to give ORCL a run for their money. But will SAP take a stance that it will only support HANA as a DB for SAP products says 5 years from now? or will they continue to support open connections to any DB? Technology alone might not be the deciding factor in the end game either.
Vijay –
Thanks for the kind words and the great questions! I’ll reply in the same order/structure as your points:
1. I heard/read about the IBM scale out solution for SAP HANA, but I’m not really clear on how this would work. There could me no shared memory across systems as the scale out happens, so somehow this would have to be a data partitioning scenario. I haven’t heard of any software solution from SAP that would manage the data partitions, move data around between machines when needed, and anyway the benefits of in-memory would seem to be quickly dissipated when data needs to be shipped around across a network. For the time being, I believe HANA is appropriate only for problems where the entire database fits in memory.
2. ORCL definitely feels heat from HANA. Larry has famously called SAP HANA “wacko” (http://www.channelinsider.com/c/a/Spotlight/Oracles-Larry-Being-Larry-Ellison-313073/). Think about how enterprises buy. Even though SAP HANA may not be productively deployed, if you were a CIO using Oracle database for SAP BW, the next time your team comes to you to ask you to upgrade the hardware (and the license) or to add users, aren’t you going to ask them – and the Oracle pre-sales consultant – to explain to you why it wouldn’t be better to just switch to HANA? When negotiating with the Oracle sales rep about your support renewal, aren’t you going to use HANA as leverage? Aren’t buy-side advocates like Ray Wang (@rwang0) going to mention this negotiating tactic with all their accounts? Even before customers adopt HANA, it will have an impact on Oracle. On top of that, there are customers who are seeing real benefits from HANA now, and will switch from Oracle (or not buy Oracle for new applications), and this will have a (forgive the paraphrasing of a failed president) licenses saved or avoided impact. As to getting out of the Oracle license, from my analysis HANA will replace some Oracle licenses for less than the cost of one year’s maintenance on the Oracle database.
3. You are absolutely right – we have yet to see Oracle’s competitive response to HANA. We should all remember that Oracle has successfully competed with free (DEC RdB) and nearly free (Microsoft SQL Server and IBM DB2) in the past, so “cheaper” is something Oracle knows how to defeat. However, “cheaper, and (for this application) better” is a lot harder! SAP HANA will not be better for every app, and customers who have Oracle today will have Oracle for a long time to come. However, as HANA covers more and more customer applications, customers will have a real incentive to switch to HANA – which will seem less like a full-fledged database and more like an embedded capability in more and more SAP solutions.
4. You are quite right that 25% of SAP BW installations will not have much of an impact on Oracle. However, I think that – a couple of years down the road – there will be a really high probability that a higher percentage of SAP BW shops would find no compelling reason to use Oracle at that point – plus Business Objects customers, SAP Business ByDesign customers, and many SAP Business Suite customers. Add to that that SAP HANA is not the only disruptive competitor attacking Oracle’s database business (Hadoop, Cassandra, Lucene/Solr), plus the more traditional competitors (IBM DB2, Microsoft SQL Server, etc.), and Oracle has a real problem cementing its cash cow business.
5. SAP Business Suite is built on a concept of a relational database, expressed in SAP’s variant of SQL called OpenSQL. I believe that OpenSQL will be supported on multiple databases, including HANA, in the future. However, I think you will see more and more SAP applications (plus what SAP calls “content,” or metadata descriptions of analytics) in the future, where these applications will require HANA. You would then be in a situation where, if you want the new SAP innovation, you have to at least have some HANA in your data center (or the cloud).
5++. Let’s call Business Suite R/4, and ByDesign R/5 for the sake of argument. I can imagine a future R/6 redesigned from the ground up for in-memory operation. In such a scenario, SAP would need to rewrite the apps to build integration across modules in from the ground up. Instead of breaking up in-memory objects into relational rows/tuples, the applications would just store their objects in memory. Of course, you’d need to stream a transaction/recovery log of some kind, to ensure high availability and recoverability – but perhaps that stream would be to a hot backup (as well as to disk). In this scenario, there is no place for an Oracle database, at least not under the transactional and analytical portions of SAP.
Thoughts? Thanks!
— Dennis
Dennis, thanks for taking time to respond .
1. I think there is an additional problem of traditional app design that makes HANA or any multicore technology sub-optimal. There is only so much you can do if the app has strict sequential instructions for the most part. The best case I read somewhere was a 20% improvement by parallelization, by doing memory deallocation in a separate background job. Maybe new generation apps are smarter to make use of massive parallel processing.
2. Here – I think you have a more positive feeling than me about the short term potential for HANA to turn heat on ORCL. With just two go live stories presented at Teched, I am hesitant to say customers are already seeing value. I think in future they will – but I doubt if they do already. With compression – HANA needs less space. But does that mean licenses will always be cheaper than ORCL for same number of users? Also CPU based licensing might make ORCL look cheaper too. Ray and other buy side experts recommending HANA is key to SAP’s success in market. However, till they see a large number of production customers – will they actually make that recommendation strictly on cost basis?
3. Right – and as SAP comes up with killer apps, there will be a better case to buy HANA. We just need to wait for a couple of them to show up.
4. ORCL does have to watch out – but considering they always had competition, and kept milking that cash cow all this time, I think they are used to this scenario by now. I am very keen to see their exact response if any.
5. Here I think an on-demand route will be the safer option in getting people to use HANA more with business suite. But it is hard for SAP with most of their revenue coming from on-premises license revenue.
5++ I always felt that this R/6 way is THE way SAP should have come out with HANA in the first place. This way, there would be no hesitation from customers to do mass adoption. The current incremental way of doing it is much more inefficient and slow in my opinion. I think SAP will just end up giving competitors time to come up with solutions the way it is done now. But then – it is harder to pull off, and I can see why they took an incremental approach to mitigate risk.
Vijay –
Excellent comments! I look forward to your blog on the topic 🙂
1. As I said, it is not clear what is the domain of applications for which SAP HANA is suitable. I think there is a good deal of potential for parallelism in HANA, especially for the “in-memory compute engine” portion of the system.
2. I believe HANA will have an impact on Oracle pricing discussions with SAP customers long in advance of HANA delivering real value to the majority of SAP customers. As soon as it appears that it is a looming threat, CIOs can use it in pricing discussions. Even if lots of customers don’t adopt HANA, its ability to negatively impact Oracle pricing makes it a winner for SAP.
3. Agreed – this will take some time! Even SAP’s roadmap had very few HANA-native apps on it by the end of 2012. Perhaps SAP can rally the ecosystem to create lots of additional apps.
4. Agreed – Oracle knows how to compete! When I was there, probably 100% of the ads I wrote with Larry were competitive in nature.
5. On-Demand (for SAP Business Suite) has its own adoption curve. I think on-prem is where the HANA action will be in the short- to medium-term.
5++. See p. 22 in that Slideshare link I posted …
THANKS!!!
— Dennis
here is a short post on the topic, Dennis
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/26606
BTW, Vijay, there is a presentation at http://www.slideshare.net/SAPanalytics/sap-hana-overview-nd-update-dec-1-2010 where SAP indicates there is a “Run Bolder” plan for the future where SAP Business Suite would not run on databases other than SAP HANA …
— Dennis
I think you hit the right point in mentioning the cost vs Oracle. However, I feel there is a lot of clarification needed in this area to see if Hana can compete against Oracle in terms of TCO :
– license cost : my understanding is that many SAP customers have contracted their DB in the context of their overall SAP contract. That means that if they are using Oracle for their ERP, Oracle is the only DB they can use with BW with no extra price. If this understanding is correct, this puts a huge challenge for SAP if they want to retire Oracle from their accounts because customers would have to unplug Oracle from all their SAP instance before recovering their Oracle maintenance costs
– cost of Hana vs Exalogic. I didn t see any papers focusing on The TCO of Hana. If they exist, I would be highly interested.
Jean-Michel –
Great comments!
I believe that the license customers get for Oracle with SAP applies only if they don’t create any custom objects/tables, and that many customers separately negotiate their database licenses with Oracle as a result. Nonetheless, great point, and I should do some additional research on this.
I don’t think there is much out there so far on the TCO of SAP HANA, but the early customers I spoke with and the interviews I’ve seen (e.g., those interviews by Jon Reed @jonerp) point to SAP HANA requiring very little administration. Another good area for some additional research as HANA matures.
Thanks!
— Dennis
Thanks for your answer. Just a precision: when mentioning TCO, I didn’t think of administration (and I fully agree on your POV, Hana shouldn’t be labor intensive for DBA’s). I was rather thinking of the hardware and software costs. Now that pricing seem to be clearer, I’m unsure that someone has yet made the difficult exercise to compare costs of in-memory DBs such as Hana vs columnar database such as Sybase IQ or Vectorwise or Infobright (which I know are not applicable for most of the SAP customers unless they “opted out” for BW) vs Appliances such as Exadata.
JMF –
I haven’t seen any comprehensive analyses. Anecdotally, SAP uses a references who switched from a $1.5M hw set-up running Oracle (?) on 20-ish blades to a low-end HANA box (around $300K). I don’t know if HANA will benefit every analytical app out there (I suspect not), but for those apps where justifiable, it should be dramatically cheaper. Why? Because it doesn’t need the expensive disks most data warehouses need, it doesn’t need the expensive DBA’s that most data warehouses need, and it doesn’t need to process as much (ergo it needs fewer CPUs). It doesn’t need to process all the disk/block management, index computation, cache management, RAID OS threads, and so much more. It’s simpler, but faster, for a large class of apps.
If you turn up any data on this topic, I’d love to have a glance 😉
Thanks!
— Dennis
Dennis, at the heart of HANA is TREX. This was never acquired, but a genuine SAP innovation.
Robert –
I had not heard about TREX’s involvement in HANA until the very last moment I was at SAP TechEd. There has been a lot of talk about the team in Korea – the team from “Transactions In Memory,” or the P*TIME product team. I’d like to learn more about where the different parts of SAP HANA came from, how they are built, and how mature each is. Any pointers? Thanks!
— Dennis
Dennis,
Former SAP BWA support guy here. I just did a webinar for TechTarget.com where I explain the evolution of SAP’s In-Memory offerings. I’m still awaiting the publication and I’ll forward it on as soon as it becomes available.
In short, the evolution of HANA, has been SAP TREX -> SAP BWA -> SAP HANA
Within the HANA stack there is a bit of TREX (columnar in-memory), P*TIME (in memory RDMS) and MaxDB (in disk db). The hardware landscape and architecture is similar to how TREX has worked since the early 2000’s, and evolved into BWA.
-mb
Dennis, you seem to make a statement about exceptional HANA’s price/performance ratio based on the opinions, and not facts. So far perfectly-oiled SAP marketing machine for HANA produces excellent adoption of the ideas, but we still lack facts – in both TCO (cost) and performance areas. HANA future in SAP installations is very promising, but we still to see its potential on the open market.
To your discussion with Vijay (because of short time I will touch only 1st point): Yes, the moment you partition the data there is an overhead of data movements between nodes and data consolidation. The issue is even with single node servers – some memory areas are further from CPU than others, i.e. we are dealing with NUMA. That’s why SAP keeps investigating the build of huge machines (one presented at TechEd was 5TB RAM prototype) using 3rd party ScaleMP software, which allows to see distributed memory as one continiuos area.
PS. Oracle’s DW appliance is Exadata, not Exalogic.
-Vitaliy
Vitaliy –
Ouch! I repeatedly say Exalogic when I mean Exadata. Confusing branding, perhaps, is my only excuse. You are absolutely right, I should have said Exadata.
As to the price/performance ratio, there are precious few data points out there. Certainly, the hardware and software list prices are facts, and I was able to verify them with several independent sources with first-hand knowledge.
Additionally, at SAP TechEd, I spoke off the record (without being arranged by Oracle) with several third parties (both partners and enterprise IT users) who had direct hands-on experience with HANA. My findings were consistent with the SAP marketing points – for the applications chosen, SAP HANA gave substantial performance improvements. The third parties I spoke with saw 50x to 1000x (and even higher!) improvements in performance, but there was a near identity in the solutions – all the solutions tested were simple number-crunching, without any updates. No planning applications, no transactional applications, no embedded analytics, no analytics against live data. In each case, customers were moving data from the production system into a data warehouse for number crunching (statistics, aggregates, sorts, etc.). Surprisingly, I spoke with two customers (one is also an SAP partner in the SI business, but speaking about an internal application), plus SAP’s IT department, where customers were doing very-near-real-time analytics, using SLT to propagate data from the production system to HANA in milliseconds.
I suspect we’ll soon have a lot more data points. Although there was a tiny minority of customers already trying HANA at the show (I would estimate it at far less than 0.5%, based on hands raised during the keynote), there was a huge level of interest in it among attendees. The HANA sessions were jammed, and the campground sessions for HANA looked like the FCOJ trading scene from “Trading Places.” I spoke to dozens of IT folks at the event, and in most cases they had an application in mind to pilot test HANA – more often than not it was an application that could really “move the needle” for their company, showing 10x or better ROI if successful.
So, in short, my blog was based on facts, but very few facts. Time will tell if SAP can make the reality match the extrapolation.
Thanks!
— Dennis
Vitaliy –
I changed the reference to Exalogic over to Exadata in the post. Thanks for pointing out the error!
— Dennis
Curious to hear who you think will be the early adopters of Hana? What types of companies? What types of industries, etc. Thank you,
Scot
Scott – thanks for the questions!
I think the early adopters of HANA will be heavy BW users, in large SAP accounts, across industries, trying it out in pilot projects.
Thanks!
— Dennis
Few clarifications Dennis as I think there are quite a few inaccuracies:
1) Your pricing is off – both for hardware and software. Your hardware cost is high and software cost is low. Software could easily be $10-20m for a high-end HANA appliance. Your guess on services is about right for a simple pilot – note that the services cost will vary wildly based on the complexity of the app!
2) I don’t believe there are any 2TB appliances certified yet (though your pricing on memory is correct). There is also technically no scale-out (larger than 1TB) appliance available yet although IBM claim they have one. It’s not scale-out though, but rather scale-up – based on the expandable (and expensive) IBM x3950 platform. That said, this is likely to change soon.
3) I believe that your compression figures are way off. If you have a 10TB uncompressed Oracle datamart, then it will typically compress 2:1 – so 5TB compressed. This will typically be a 1TB SAP HANA database. Note that if you export this same 10TB uncompressed Oracle database to ASCII, it will also be about 1TB. So there is actually *NO* compression from ASCII flat file to HANA database.
4) Your Oracle licensing point is very subjective unfortunately, since many customers either license Oracle for 11% of their SAP license fee as an annual subscription, or via a global license agreement. I’ve not encountered a SAP customer yet that would save any Oracle license revenue by implementing SAP HANA – although obviously if you replace all your SAP Oracle databases, you could indeed save your 11% per annum. So Oracle don’t have anything to worry about here yet.
5) I’m not sure on the Exadata vs HANA performance comparison – it’s very subjective. I suspect that for many apps, both provide excellent gains, and Exadata is already certified as the RDBMS for NetWeaver, which is neat. That said, HANA ought to massively outperform Exadata for complex calculations on large data sets – although benchmarks are obviously nowhere to be found!
By the way, I like the article and I agree with the conclusions, although it is unclear so far what the maturity curve is for SAP customers considering running HANA on BW. Please remember that for most SAP customers, BW is business-critical. Not business-critical like store replenishments or manufacturing process, but business-critical in terms of month-end financial process, for example. As a result, many BW customers will be risk-averse.
John –
Thanks for the great comments.
1. My estimates could easily be off, since SAP won’t officially state pricing and because customers get offered various deals. However, on background, several SAP folks told me that the software for a high end HANA appliance would be in the $1M to $2M range. It could be that my/their definition of high end is lower end than yours – I asked them about a single HANA appliance tricked out, so that would presumably be a 2TB system with the maximum number of cores. They also said some confusing things about the metrics on which HANA pricing is based, but they were very clear that $1M to $2M is the top end. I’ll reach out to you offline to see what you’ve heard! As to the hardware, I think the lowest you could get in for would be around $40K, but from the customer discussions I’ve had, they recommend a configuration that prices out between $80K and $100K for their pilot projects.
2. I think you’re right that no 2TB appliances have been certified yet, but I think several are in the works. I believe that the lowest end pricing for a 2TB rack-mounted system capable of running HANA would be in the $300K range. Don’t forget sales tax 😉
3. Again, your mileage may vary, but (bearing in mind that I have not installed or used HANA personally) there is plenty of opportunity for compression vs flat file – that’s the whole point of columnar storage – you get good compression on columns that have lots of redundant values (e.g., product code for sales data, employee id, temperature readings in process data).
4. Many customers are paying 11% for the Oracle license, which still leaves some room to pay for a HANA system under BW. However, because many customers want to add their own tables, or they use Oracle databases for other reasons and therefore can do better with volume licenses directly from Oracle, many customers end up buying the Oracle license from Oracle and paying the maintenance directly to them.
5. Totally agree with you on performance – mileage may vary.
John – great comments, and you ask all the right questions. The maturity of the solution is definitely a question mark – how reliable is it, how often does it go down, what is recovery like, how does it work if you have many users or several applications, … ?
Thanks!
— Dennis
Great answers.
1) High-end is definitely relative! I’d say it was the biggest scale-up appliance you can buy right now: 4TB. The software license for that is just under an 8-digit number. $1-2m for a 2TB appliance is… low 🙂
2) $300k-ish sounds reasonable (probably closer to $350k) but the reality is no-one will buy the big 2TB DIMMs if they can avoid it. You need 64x16GB DIMMS @ $500 each (approx $32k) for 1TB or 64x32GB DIMMS @ $4000 each for 2TB (approx $256k). Those big DIMMS cost!
3) I’ll give you some stats on this when I’ve done a data load in the near future. What you say is theoretically correct: you will get compression of these values, but you will also get white space elsewhere. What’s clear though is that you get much better compression than you get in an Oracle or IBM DB2 RDBMS.
4) Sorry I explained my point badly. If you pay 11% to SAP for your Oracle license, and then buy HANA and therefore no longer use Oracle for BW, you will not save any money at all. This is because you will continue to use Oracle for ERP (for example) and therefore still have to pay 11% of the total. The only way you can lose that 11% license fee is if you get rid of Oracle altogether and use HANA for the Business Suite.
Interesting on US sales tax by the way. In the UK we have VAT, which is deductible for business equipment sales and therefore only a relevant concern for cashflow. Looks like in most US states, if you are the end-user of for example a SAP HANA appliance, you will have to pay your sales tax. Learn a new thing every day.
John –
I’ll reach out to you via e-mail.
1. I think we are getting differently signals on pricing. For SAP HANA under SAP BW (swapping out an Oracle database), I think customers are looking at numbers an order of magnitude lower than you’re quoting.
2. I’ll do another post about how SAP HANA supports scale-up and scale-out – there is a way to get to larger data sets without buying more expensive RAM.
3. Data scalability is a good topic for my next post as well.
4. I’m not sure you have this one right. I think the embedded license is per contrracts – if you bought Business Suite on a different contract than you bought BW, then you can drop Oracle from your BW instance and save the maintenance. I’ll check up on this.
Thanks!
— Dennis
dear expert,
presently i’m learning sap-bw/bi.i want to start my career with sap bw/bi.but now many of people saying that sap-hana will kill sap-bw/bi in coming one or two years.Is it true?
let me know about this overall confusion.please reply me as early as possible.
Thanks®ards
Basha
Basha –
I think those people are incorrect. SAP HANA is complementary to SAP BW; SAP BW runs on top of SAP HANA, and is better because of SAP HANA’s performance benefits. Some of the design considerations that you would use with SAP BW are different when using SAP HANA as compared to using SAP BW on Oracle or another traditional relational “disk-based” database, but understanding how to design SAP BW in either case is important.
Let me also add that pricing information on SAP HANA has recently become more apparent. SAP HANA is priced high enough that many SAP BW customers will not adopt HANA quickly. In addition, customers are reporting stability issues and other limitations. In short, although SAP HANA provides extraordinary benefits to many SAP BW customers, it would appear that many BW customers will continue using BW without HANA for at least a few years.
I would recommend that learning SAP BW is a good choice at this point and for at least the next two or three years. If you had to choose between learning BW and BusinessObjects, I might lean towards BusinessObjects, but both can operate with or without SAP HANA.
For more information on these topics, try contacting @vitalbi, @applebyj, or @vijayasankarv.
All the best,
— Dennis
Hi,
i m new to asp hana..How to start with sap hana
How to istal the s/w in my system
I want to have hana on top of Oracle,how can i pull real time data from oracle to hana
Thank,
Amit
Nice explanations, however there are some wrong descriptions.
1. HANA is not a replacement for Exadata.
2. Pricing is totally wrong, the full Exadata costs around 1.5 mil. usd. That is a database server, which you can consolidate your data not only for performance but stability, availability and security.
3. As long as you run your SAP ERP on Oracle you shoud go on paying 11% maintenance, so you will not save anything.
4. We migrated SAP systems to Exadata and the data is compressed 10x.
5. The ERP and the BW performances are at least 20x better. the backup performance is 10x better.
6. HANA is just an application server, serving between the DB server and the clients.
Regards
Sorry for the late reply – just saw your comment for some reason.
1. Well, there are plenty of use cases where HANA is an alternative to Exadata.
2. Moving target – depends on config, but that’s a reasonable assumption.
3. Don’t agree on this one.
4. 10x on Exadata? You are very lucky compared to the other Exadata customers with whom I spoke.
5. What is 20x better? ERP and BW on Exadata? Again, you are very lucky (or very good, or not entirely honest) compared to the other Exadata customers with whom I spoke.
6. Not true.
160K EUR + 15% to Oracle for SAP HANA Enteprise Edition 64GB RAM Unit.
1 TB HANA EE cost = 2 560 000 EUR + 384 000 for DB = 2 944 000 EUR = 3 Milllion Euro.
Funny isn’t.
Wow –
I don’t understand your comment. Why would anyone pay Oracle 15% for HANA?!? Sorry, I don’t understand.
– Dennis
Thanks Cengiz, it’s nice to finally see something on here that isn’t biased. I like how much Oracle is neglected and undermined by you guys due to being sponsored by Workday. And not only against Oracle but if any company and Workday are mentioned in the same blog post, then all I see is the other company being bashed. I came on here for influencer analysis that is independent so I can make an informed purchase, but I guess I came to the wrong “Independent” blog with a hidden agenda. Tell Workday they have lost a potential customer.
POR –
FWIW, I am not in any way sponsored by Workday.I have written only one blog ever on Workday, and it was mostly positive but did not compare it to any other ERP product. Unlike most other Enterprise Irregulars, I use Workday at work, and on the whole I like it.
Thanks anyway …
looks like oracle is not the only target, SAP just moved on Microsoft as well
http://businessintelligist.com/2012/11/21/sap-hana-vs-microsoft-sql-server-the-war-is-on/