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

The database needs to be able to scale out and in without disruption or delay.

Software vendors moving to a SaaS business model are usually optimistic about the prospects of the product(s) and the company. Making an investment in a change like this implies a hope for growth.

This dynamic has actually been true for the vast majority of the data projects I’ve been involved with at clients. Other than projects done just for regulatory reasons, the hope is that the project takes off and supports sales, new market penetration, product line expansion, etc.

Projecting the growth is exciting, yet difficult, and there is a clear knock-on effect of this on projecting the data growth. Growth estimates are usually wildly off. Projects tend to out-perform expectations (a good problem) or underwhelm and eventually get shut down. Out-performing expectations means more data for the database than anticipated. With scalable systems and proper monitoring, database professionals have been able to adapt, although this has imposed work cycles on the organization.

More importantly, by definition an on-premises system must be over-specified so resources do not run out. On an automatically monitored system with access to practically unlimited and ready resources such as a cloud, the over-specification – and hence your wasted costs – is negligible. This is the promise of the cloud – immediate access to the resources you need.

The exact level of resources necessary should not only be what is provisioned, it is the cost basis.

A cloud database needs to be able to scale out and in without disruption or delay. If it takes hours or days to scale (in a typical relational database, this means up or down) or creates disruption for migration or repartitioning efforts, one of the key benefits is lost. The more granular the growth of the clusters, and the less of a “step ladder” approach to resources, the more elastic the solution is.

Deciding ahead of time what the next rung on the ladder looks like – or negotiating it in haste – is not true elasticity. The more proactive and involved a customer has to be in the process of resource determination, the less elastic the solution is.

If cluster expansion requires either downtime or a series of manual data copying to sync data from an old to a new cluster or database storage capacity is fixed to the node type (compute dense or storage dense), it’s not fully elastic.

This elasticity extends to upgrades. The cloud database software, like NuoDB for example, should be able to be upgraded without any downtime, performance impact or interruption of service.

Software vendors moving to a SaaS business model are in a unique position to appreciate the lack of over-commitment of resources and the cost savings that are leveraged throughout the customer base and should be sure to seek true elasticity in their database of choice.