There are many choices for your next database project. Of course it depends somewhat on the types of information you’re working with, and the types of functionality you require. In addition, up-time requirements will likely come into play.
But what if so many of the different access methods you have today were possible and you could pick the engine behind them? What if you didn’t have to really worry about scaling and such. Not to sound like an advertisement (and I realize it does), but this is fast approaching.
The thing that had the thoughts flowing in this was the work with Cosmos DB that is going on, and the functionality the Azure space is providing through this platform. It is compatible with all sorts of access protocols that you may already be using, and even more interesting, Azure seeks to just remove the processes of tuning, scale out and administration.
What happens to the decision process for selecting that next database platform for the next project? My suspicion would be that you’d be looking at a completeness of support, and ability to provide for ongoing growth and such. Your selection criteria is likely to get very fine-tuned when so many of the variables become just … standard.
Cosmos DB is interesting on a number of fronts because you can access it using NoSQL type queries, you can use SQL (DocumentDB-style) and more. What’s more, you can also use SQL – returning information in a standardized fashion that you can put to use in your applications.
The database also self-tunes in terms of indexing and performance tuning work.
Given all of this, I suspect there will be far fewer decision points. Things to consider:
– How hard is it to get support for the database environment? (Not only DBA-type support but also developer-type support for your projects. How many have used and are developing against it? There are a LOT of people that fall into this category, but you’ll need to judge your available audience.)
– Costs for deployment for your particular requirements. Since Cosmos DB is a cloud-based service, you might correctly expect that it’s billed on a usage basis. Depending on how well you know your audience, users, requirements and such, costs may vary as you deploy it.
– Other applications that may need to interface with it – while certainly not impossible, it is a planning point that needs to be considered if you have other applications, other platforms that you’re supporting. Adding a new platform may be painful and a steep learning curve, and may require development on existing applications and infrastructure.
It’s not the end of… well, anything. From relational to DBAs and all of that. It’s there to be a great tool, to remove variables, to let people focus on the application and functionality, rather than the mechanics of storing and accessing information. It seems like a very strong iteration to be considered as you define your tool chest of database tools.