How to choose the best database for your app?

Choosing the best database is one of the most vital elements to create a successful app. Taking the advice of providers or using one just because you have it may be more comfortable but cheaper, but it’s probably not the best way to go.

There are many elements to consider to make the best choice. How much data will you handle? How many users will use it simultaneously? How often will you change schemas? What is the natural shape? And so on. It would be best if you made your pick based on this and other questions. Here we’ll go through some of them.

How much data do you expect to store?

If your calculations are in gigabytes, then, this is a non-factor. If you are in the terabyte range (from 1024 GB), there are still plenty of options. Now, if we’re on the petabytes field (millions of gigabytes), options are way more scarce, and you’ll need a substantial budget for a tiered storage option.

How many simultaneous users do you project?

Before installing your database, you have to estimate the number of simultaneous users you expect. Lots of databases cannot handle thousands and thousands of users accessing petabytes of data. Clearly, the estimate also depends on the use of your database. An internal database is much easier to estimate than a public database and even way easier to cover.

What about availability, scalability, and such?

Availability is vital. Not all apps need to run 24/7 with full availability, but it depends. Some cloud databases give you 9-to-5 availability, while on-premise databases may give you almost full availability.

Scalability is something you need, too. Horizontal scalability is way better for No-SQL than SQL. Dynamic scalability is way easier for cloud databases. Good scalability is key if you’re awaiting a significant amount of simultaneous users.

Latency refers to the response time of both the database and the app. You usually want sub-second latency for simple transactions. Depending on your database, analytic queries may take seconds or minutes, will your users hold for those minutes?

What about the stability of your database schemas?

If they won’t change much in time and you want consistent types, SQL databases may be the way to go. In other cases, NoSQL databases may be better, as they sometimes don’t even offer schemas’ support.

Do you need transactions, analysis, or both?

If you need fast transactions, you need fast write speed with little indexes. If you need analysis, you want lots of indexes with fast read speed. Some databases are faster at reads others at writes. Your pick depends on the mix you expect.

A few concluding tips

First of all, remember it’s not just a question of SQL vs. No-SQL database. What matters the most are features like structure, size,  speed, and scalability.

Also, an excellent way to understand what you need is using data modeling, as it’ll help you map the main features of the app into the data structure. That will give you a much better picture of the kind of database you’re looking for.

Likewise, don’t close yourself into one particular type of database. You may need to combine them. While modeling, you may find out that some queries cannot be optimized in the data structure you’re using. That’s normal. You can adopt a variety of databases as long as they own specific data sets.

All of these considerations will help you choose the optimal database(s) for your application so you may offer a better service.