This sponsored post is produced by IBM Cloud Data Services.

Mobile applications promise to transform your brand and cement its position in the minds of your audience. But at their core, these apps are about generating new types of data and using that data in new ways.

If your application grows according to plan, it will be retrieving information from its database at a rate of millions, or billions, times a day. 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 points to consider to help make your next project a success — and some common mistakes that happen when they’re not considered.

Scale for launch

Will your next app launch grow like Fitbit® or stumble like

When 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. For example, data access should be prioritized in applications designed to engage with users. Data consistency might be more of a priority for applications with interrelated, multipart transactions. Likewise, experienced people must be paired up to manage ongoing database performance. failed on both counts.

Design for offline

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 his or her phone lost its signal can 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 and plan for offline-first data access. 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.

Hardware upfront or over time

As more people use your application, you will have to add more horsepower to the computer hardware running your database software. With those computers come costs, and you will have to decide whether to pay them upfront, or pay them as you grow.

The big, entrenched database software companies will squeeze you up front on hardware. It’s a great approach for them, and it has worked well for the past 30 years. Every dollar you spend only increases the cost of your risk and locks your app into their technology.

Newer databases can run on cheaper, commodity computers. They also tend to embrace the efficiencies of cloud pricing, allowing your application to add hardware as you go. The best part is that you pay only for the computing power you need.

Mike Broberg is Ecosystem Editorial Lead at IBM Cloud Data Services.

Dig deeper: Read more about freemium, managed service, and on-premises database deployment options from IBM Cloud Data Services.

Sponsored posts are content that has been produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. The content of news stories produced by our editorial team is never influenced by advertisers or sponsors in any way. For more information, contact