Mobile applications and Internet-enabled goods promise to transform your brand and cement its position in the minds of your audience. At their core, these apps are about generating new types of data and using that data in new ways.
You don’t have to be a software engineer to know that your team’s choice of database matters. Unfortunately, there is no one-size-fits-all solution. Without knowing the specifics of your organization’s goals, skills, and IT architecture, no software vendor can honestly tell you if their database is the right one. What we can do is share some common mistakes we’ve seen and points to consider to help make your next project a success.
Disaster of scale
Will your next launch grow like Fitbit® or stumble like HealthCare.gov?
When HealthCare.gov launched, some of the most important parts of the site were built on a new kind of database technology called “NoSQL.” The NoSQL database vendor did not build a bad product. In fact, it had a track record of success in large e-commerce applications. The problem was the company hired to integrate the database with the other, more traditional government technology on the project did not know the best ways to apply NoSQL concepts. The result was an application that was inefficiently implemented and not thoroughly tested to handle high volumes of users and data.
Millions of users can cause a database to grind to a halt. To succeed, the right database software must be paired with your application requirements. Likewise, experienced people must be paired up to manage ongoing database performance. HealthCare.gov failed on both counts.
Disaster of microdowntime
It’s annoying if you can’t access the data you need the moment you need it. Anyone who can’t use a mobile app because their phone lost its signal could tell you that.
This is the effect of “microdowntime.” From the perspective of a single user, your app is broken. To them, not being able to use an app because it can’t access the data associated with it is just as bad as your entire data center going dark.
Unfortunately, many apps are designed to depend on a reliable network to access and update data. Data that keeps track of things like “Tasks I was assigned today,” “My workout plan and history,” or “My frequent flyer status.” No connection to get this data, and the app is useless.
Some databases take a more realistic approach to the unreliability of networks. They store data directly on a user’s device instead of retrieving it from a remote server. Because the software and its data are packaged together in a neat little bundle, things just work, even in airplane mode. The application becomes independent from its network connection. The result is an app that works as well offline as it does online, and a satisfied user.
Disaster of context
Location data can add valuable context to your application, but some database software handles it better than others. Ultra marathoners have extreme training routines. The following anecdote is equally extreme, but it illustrates how two databases can process the same location data differently.
To compete against her friends, an ultra running enthusiast was training with both a running app on her phone and with a GPS watch. As the miles piled up, she noticed that the GPS data was several miles off from the data stored in the app. Further investigation revealed that the app’s database relied on a geometric model that represented the earth as a perfect sphere, when the earth is actually an ellipse. A discrepancy between how different database software represented the curvature of the earth accounted for the difference and could mean the difference between customers using your app or not.
If you care about where your customers are using your app – or want to delight them with the most accurate search results and targeted promotions – how your database handles geospatial data matters.
Read more about app deployment disasters and how IBM Cloudant can help you avoid them.

Comments have been disabled for this post