Know Your Embedded Database Cost

This post is sponsored by NuoDB.
All thoughts and opinions are my own.

In the move of a software vendor to a SaaS business model, database costs can escalate if the architecture and license model is not built for the cloud.
This blog concludes the Mount Rushmore for choosing the database for software vendors moving to a SaaS business model. I have previously covered SQL functionality, true elasticity, and ACID compliance.  
The database will be replicated throughout your customer base unless it’s shared in a multi-tenant application, which means you’ll be dealing with one large, and very critical, database. Regardless, it is not an exaggeration to say your database vendor choice will significantly define the cost structure to serve your software. If the functionality is covered (for now and the future), it comes down to cost. You will seek a low and predictable TCO for your database, all things being equal.  
License pricing can be complex and unpredictable, even for the same product – and over time. You want to deal with a vendor who is very transparent about costs and promotes their pricing at the Mount Rushmore level.
One common pricing model is per-storage or per-server/per-core. A similar model that database vendors offer is user-based, which can be distinguished by user class. There are also tiered per-distinguished-user model, where you can fit your profile into one of a few user buckets, with descending per-user costs that cost out at a fixed, recalculated cost per year.  
Others use a data source model. I don’t prefer, or recommend for my end clients, cost models that can unduly influence architecture. Architecture should, and can, exist outside of the cost structure for the underlying software. Source pricing penalizes software companies for database count. This model will also create cost chasms to ecosystem growth.
However, the database architecture can drive pricing by providing options. While any database can be placed in the cloud, there are certain cloud features that customers have come to expect from cloud software, yet may not be getting from their database of choice.  One key feature necessary to be cloud-enabled is the ability to independently scale compute and storage through specification of nodes with emphasis on one aspect over the other.  This alleviates compromise in the resource allocation and unused costly resources.
You only pay for what you use, when you use it. Compute and Storage are independently priced. Database software from an on-premises age assumes those are all tightly coupled. In that approach, you are forced to pay for compute and storage even when you aren’t using it.
A solution built for the cloud should allow you to use and pay independently for the storage and compute you need. This arrangement is important to have in the foundation of the cloud database.
NuoDB has this approach to their pricing model. Compute, storage and pricing scale independently. Pricing is lower on a per-core basis as well. Compare list prices to Oracle and SQL Server here.
This architecture also works well if you have seasonality to your data and compute needs. With true elasticity, you get the right compute, storage and pricing for what you need.
If you are creating new product lines or converting an existing product portfolio, the database in the transition is one of the most important decisions. This series has given you the top four database requirements in the move of a software vendor moving to or engaging a SaaS business model: Full SQL functionality, true elasticity, ACID compliance and finally, a costing model that provides low TCO through the ability to separate compute and storage.  Manage your client’s “gold” – their data – and therefore your success, according to these four. Customers will see the value and you will see the agility and the valuation result.

William McKnight is a contributing Analyst at Gigaom. Read Bio »