Essbase 19c – Pricing Options

Essbase 19c appeared on the Oracle Cloud Marketplace back in September 2019, but that initial release was only available on a “BYOL” (bring your own license) basis. That meant that only customers who already owned – or went out and bought – on premises licenses were able to comply with its license terms. The list price for a single processor on premises Essbase license being  USD138,000 – plus a cool USD30k and change for annual maintenance – this presented a barrier to entry for potential users accustomed to subscription or usage models for cloud systems. It was also a problem for medium sized consulting shops and people like me who had been in the habit of running the local installations permitted under previous license terms for educational purposes. I’m sure I was not alone in making this point frequently and vigorously to Oracle (aka harassing Product Management) and I’m glad to report that an additional Marketplace option has now appeared under which Essbase is licensed on the Universal Credits Model or “UCM”. This means that there are two competing pricing models for Essbase 19c on Oracle Cloud Infrastructure. So how do they pencil out?

Caveat Emptor

First, a disclaimer: I’m exploring this stuff for the first time on my own (corporate) account. It can be tricky to identify every chargeable component in a stack, or in some cases every situation in which a sometimes-free component might become chargeable. While I hope the below math is correct, you must do your own due diligence and, if relevant, talk to your own Oracle Sales Rep before making any decisions.

Choices, choices…

Generally speaking, there are two pricing models when using universal credits (“universal” meaning credits you can choose to spend on any product) in the Oracle Cloud stack – a “Monthly Flex” model, and the “Pay as You Go”  model. The fundamental difference is fairly self-explanatory but the benefit of a monthly commitment is that it also entitles you to access the most preferential prices. Generally speaking, “Pay as You Go” carries a 50% premium over the “Monthly Flex” pricing. For regular production systems with predictable usage levels, “Monthly Flex” is going to make more sense, but if you’re running a personal account for educational purposes bear in mind that you will always be paying higher prices.

Assembling the Pieces

So what are you actually going to need to pay for running Essbase 19c on OCI? There will likely be some amount of the following types of service:

  • Essbase License
  • Compute – virtual machine ‘power’ (processor and memory)
  • Block storage – this storage is effectively ‘disk’ that is used by plugging in to a virtual machine. For Essbase, it will contain the operating system, Essbase software and cube data storage
  • Object storage – this storage type contains items that can be accessed without needing to be plugged in to a virtual machine (e.g. via API)
  • Database – just like on premises systems, Essbase 19c requires a relational repository. The Marketplace instantiation procedure can create an Oracle Autonomous Transaction Processing database for you, or you can use an existing Autonomous or DBaaS instance
  • Security – although the Marketplace instantiation procedure gives the option to use ‘native’ security this is probably not best for a production system. Oracle’s security provider is Identity Cloud Service (IDCS). In “Foundation” version IDCS is free; for “Standard” version pricing is per user per month
  • Networking – networking costs will depend on bandwidth consumption and other setup considerations, such as whether a bastion host is used

For a production instance, I think it’s likely that the storage, networking and other ‘peripheral’ costs are likely to be much smaller than Essbase License and Compute (not to mention, they will be the same no matter how you choose to buy Essbase 19c). Database is arguably on the cusp by this criterion; the Marketplace instantiation process offers the helpful option of creating a relatively expensive Autonomous Transaction Processing instance, but if you’re willing to handle creating and managing the database yourself, Database as a Service can be much cheaper. At around USD2.50 per hour, ATP database costs might be a significant proportion for a small sandbox environment and using DBaaS (around USD0.40 per hour) saves a useful proportion.

Do the Math(s)

All those caveats aside, let’s estimate the list price cost of a decently sized (VM.Standard2.8, which means 8 OCPU and 120GB RAM) Essbase server with 2TB of block storage running 24/365 under the different licensing / commitment regimes. The input rates are as follows (all values in USD):

  • Essbase BYOL per processor (converts to 2 OCPUs) – 138,000
  • Essbase BYOL annual maintenance per processor – 30,360
  • Essbase UCM Monthly Flex license per OCPU hour – 1.6411
  • Essbase UCM PAYG license per OCPU hour – 2.4616
  • VM.Standard2.8 Compute per hour – 0.5401
  • Block Storage per GB per month – 0.0255
  • Autonomous Transaction Processing Monthly Flex per hour – 1.6801
  • Autonomous Transaction Processing PAYG per hour – 2.5202

I’m going to disregard networking, object storage, storage for the database instance, security and so on because I believe that they will in a typical environment, be much smaller than the above costs.

The results:

19c Pricing options showing annual cost of UCM Monthly Flex to be 135k vs BYOL Monthly Flex to be 142k

The Takeaways

What jumps out is that – assuming that OCPUs perform similarly to on premises processors – licensing via UCM with Monthly Flex looks like a pretty decent deal vs BYOL, given that there is no up-front license cost. Also that the ‘flexibility’ of PAYG carries a probably unjustifiable premium for a production-sized instance with associated availability.

A few of things to note about this simple methodology. First, if you were seriously considering buying on premises licenses (rather than being an existing customer using existing licensed capacity) to qualify for BYOL terms on an OCI installation, you would need to consider how to amortize that cost and also whether you actually paid list price for your licenses / maintenance (my experience is that sometimes purchase price is discounted but maintenance isn’t). Second, there is obviously a lot of potential to save on the UCM options if your system – or some environments in it – do not need to run 24/365. Third, as noted above, for a predictably used system there is really no reason to want to use the PAYG model. This is more applicable for development, education, evaluation, prototyping and so on.

One final thought that might be of interest to customers with existing on premises licenses. Named user licenses (list price USD2,900 per user) have not been much in favor in recent years. However, if you do own named user licenses, you are able to use 19c in the cloud on the same fundamental basis. That is, Oracle don’t care about your CPU or OCPU capacity, as long as you don’t exceed your user count. Dedicating one or two of your named users to an Essbase 19c system on OCI would be an extremely cost effective way of spinning up a very high-powered environment to investigate how well 19c on OCI handles your real-world workloads.

3 thoughts on “Essbase 19c – Pricing Options

  1. Tim – This is pretty good. However, it should be mentioned that DBCS can be used instead of ATP if a customer wants to lower costs. At present, there is no performance gain by going ATP over DBCS. Also, if a customer already has DBCS or ATP, they can use that instance versus purchasing a new one. The customer can also use their DBCS or ATP environment for other schemas outside the Essbase ones. Of note…Items in the BOM other than storage can be stopped and started. Obviously, storage cannot. Finally, when a customer chooses their instance look and feel, there are automatic discounts that get applied to the instance costs once the MRR reaches, at least, $5k/month.

    • Thanks Sarah, yes – I think I did note that (DBCS option) in relation to “sandbox” environments where DB takes up an even larger %-age of total cost, but it’s true for larger installs. I’m not really sure why the ‘default’ has been chosen to be ATP. Cynically, to sell more ATP instances, less cynically because ATP has lower admin hassles than vanilla DBCS? The discount information is really good to know too. Do you know if there’s a published reference for that or is it “per your friendly Oracle sales rep”? 🙂 Regardless, 19c seems like a really good deal against on-prem right now, and at worst comparable to the old “OAC Essbase” pricing.

      • Your cynicism is correct on both fronts. 🙂 If you like admin’ing DBCS instances, you can pay less to do so. If not, ATP is your friend. I do not believe the standard discounting tiers are published, but at the Monthly Flex rate, if your total cloud for IaaS and PaaS services is, at least, $5kUSD, then discounts start being applied above the PAYG to Monthly Flex rates. Regarding the actual pricing, the UCC model roughly, if not nearly perfects, against OAC Essbase pricing. If a customer is BYOL, it is worthwhile for them to ask for Essbase BYOL on DBCS, Essbase BYOL on ATP, Essbase UCC on DBCS, and Essbase UCC on ATP pricing. Each option has it’s strengths but some may cost considerably more than others, depending on the beefiness of their environment. It really is a customer choice…sometimes the trade-off is well worth the (lack of) effort.

Leave a Reply to Sarah Zumbru Cancel reply

Your email address will not be published. Required fields are marked *