Longevity beats Functionality

The single most important factor is whether your database will still be around a decade from now. Just as we saw market consolidation in the late 90’s, we’re going to see it again and 80% of the hundred or so current offerings are not going to be able to survive.

This applies to Open Source products as well as commercial ones.  If you are serious about using Open Source, you’ll need a clear plan for how it will be supported. Will you buy support or will you fix it yourself? What will this actually cost? What happens if it’s abandoned by its users?

In practice, there’s only one thing that’s more depressing than the realization that your favourite Open Source database is no longer trendy and is not being maintained –It’s having your boss mention that you’re the guy who picked it for the company during your annual review.

For commercial products there are other ways of ensuring longevity, but these will generally involve language in your contract with the vendor.

Technical merit is not the only factor that determines success.  Mindshare and developer enthusiasm are just as important. So having established that we appear to be in a re-run of the’ VHS vs Betamax’ scenario, how do we pick our DB(s)?

More than One Platform

Don’t try to pick one magic database that has all the features you’ll l ever need. You should be looking for the minimum set of features needed to solve a specific class of problems, and should regard extra features you don’t need as liabilities. Disliking extra features is at first sight counterintuitive but, as my last post made clear, these reduce speed by anything up to 20X.

The ‘Persistence Zoo’

You also need to avoid having too many different databases. Here at Openet, we have the concept of the ‘Persistence Zoo’ – The smallest possible ‘Zoo’ of databases that we need to do our job. The ‘Zoo’ analogy is useful because it decouples databases from one single application, forces people to confront the costs involved, and highlights the pointlessness of having two near identical residents, such as both African and Indian elephants.

It also gives us a rational basis to handle requests to use additional database technologies. We’re running a Zoo, not an Animal Shelter, and this is something we can make clear when developers bring home something they found on the internet.   

Test, Test, Test!

There is no substitute for this. Do not believe any claim until you have seen it with your own eyes on your own hardware and own data.  Testing will reveal whether something is a real contender as opposed to an escaped PhD project. It will also allow you to sharpen and clarify your definition of what you actually need. 

Evolution and Roadmaps

Most database products have elaborate plans for the future. Always be aware that such plans are dependent on an underlying architecture that is compatible with the desired new capability.