Click to learn more about author Jeff Boehm.

Independent software vendors (ISVs) are on the front lines of an on-demand market, one in which their customers require immediate and continuous access to services and applications. As such, they are turning to the cloud to support elastic scale, rapid growth expectations, and a “pay as you go” subscription service fee model to decrease implementation and financial risk. The difference from what they’ve done in the past is that they’re moving from an on-premises model to a service model – and they need to do it without sacrificing their core data management platform.

Suddenly, ISVs need to be responsible for uptime and service level agreements, disaster recovery, matching capacity to volume, and latency. All of these add up to the high cost of not just the initial migration to a cloud delivery environment but also to exorbitant ongoing costs. So how then to begin bringing those costs down?

Ultimately it comes down to architecture and priorities. There are effectively four core database options:

• Traditional relational databases
• NoSQL databases
• Cloud-based relational databases or database as a services
• “NewSQL” databases

Let’s take a look at each of those individually.

Traditional Relational Databases

Dominated by megavendors (e.g. Oracle, Microsoft SQL Server, IBM) and open source options (e.g. MySQL, Postgres), these databases have an advantage in that traditionally on-premises applications are already architected to support two or more of these databases. As a result, you can minimize application layer changes and reduce time to market.

Unfortunately, such monolithic, single-server systems often struggle to capitalize on cloud advantages such as on-demand capacity, commodity hardware structures, and distributed computing. The result is that this strategy can easily result in the highest total cost of ownership and an architecture that does not scale elastically with the cloud applications.

NoSQL

NoSQL databases have exploited this inability of traditional RDBMSs to meet modern application requirements. Well-suited for cloud delivery, NoSQL databases can typically scale out elastically and support continuous availability, but sacrifice both SQL and ACID semantics. As a result, a lot of application code needs to be rewritten and new skills need to be acquired to absorb the complexity that would otherwise have been handled by the database.

These changes mean that a NoSQL strategy lengthens the time to market and can increase the difficulty in updating and maintaining the application code itself due to the absorbed data management complexity.

Cloud Databases or Database as a Service

As more organizations become comfortable with public cloud deployments, cloud databases from Amazon, Google, and Microsoft have become prime candidates as well. Typically based on familiar products such as MySQL, these products have the advantage of a familiar database in a cloud environment, but often suffer the same single node disadvantages of their on-premises implementations as it relates to provisioning, elasticity, and even distribution. That means continued reliance on clustering, replication, and sharding to meet your availability and performance needs.

NewSQL

In a recent academic paper, Matt Aslett, Research Director at 451 Research, and Professor Andy Pavlo of Carnegie Mellon University define a new category of databases called “NewSQL” as “a class of modern relational DBMSs that seek to provide the same scalable performance of NoSQL for OLTP read-write workloads while still maintaining ACID guarantees for transactions.”

NewSQL databases offer the scalability NoSQL systems provide without sacrificing the transactional consistency and SQL-based model of traditional relational databases.

That’s not to say that NewSQL isn’t without its detractions. Unlike using legacy or cloud databases based on legacy systems, NewSQL requires some minor code review to eliminate database-specific idiosyncrasies – though infinitely less work than it would take to port an application to a NoSQL system.

Conclusion

Ultimately, migrating an application to the cloud means identifying the right cost and architecture structure that satisfies customer requirements while keeping the total cost of ownership low.

For some situations, speed to market is more important than ongoing costs, and for others, extreme elasticity is worth sacrificing consistency guarantees. But for the majority of applications, NewSQL solutions provide a compelling alternative to other existing options.