A key question when you start mobile app development is the choice of database and backend. With over a decade of experience in mobile app development, we can say that every app is different and each requires a unique approach.
Choosing the right database and backend is about understanding the data and what it will be used to solve. The debate is not SQL vs NoSQL, nor is it Firebase vs Couch. If you lead from these choices, the incorrect decision will be made. Here are three key questions to ask when discussing your database and backend requirements with your developers:
- Structure: What type of data are you storing and what format will it be retrieved in?
- Size: How much data will you need to store and retrieve?
- Speed and scale: How quickly must this data be shown or data be stored? Is it read heavy or write heavy?
Let’s take a look at the options of databases and backends for a basic understanding of how they work. The below serves as an introduction to the types of databases so as to make the terminology as you enter the world of mobile app development a little easier.
Database Selection
Use database modeling to understand what database would be best suited. This is an exercise that your mobile app developer team can take you through.
SQL (Relational)
Think of relational databases as you would think of a spreadsheet. A table with rows stores information which can then be related to each other. Relational databases puts effective data storage – no redundant data – and data consistency in the center. This is good for querying data and the analysis of information. It is well tested and popular as it was one of the first database technologies ever built. However, with apps using vast amounts of data, relational databases don’t always scale well, and a new look at how we store data was needed and thus NoSQL.
Examples of Relational SQL databases: Oracle, Microsoft SQL Server, MySQL (now owned by Oracle), IBM Db2 and many more.
NoSQL (document, object, graph)
The NoSQL revolution came out of the necessity to handle vast amounts of data and the need be able to scale.. But this came with tradeoffs. The biggest difference is the way that the information is stored. The data is not stored in a table format but it is stored in a document, object or graph format. One big advantage of not using tables is that it makes it easy to change and extend the data, since you are not bound to a specific structure or schema. This can make it easier to add new features and shorten development time.
Document
For this, it is easiest to think of a scanned document within which each part of the document is a value. For example the header is a value, each paragraph etc. The contents are indexed for fast retrieval.
Object
Data is no longer stored in tables, but is stored within the object. The benefit of this is that it is easy to update all users immediately. One update, updates all views. Interestingly, Lyft uses an Object database for their ride sharing app.
Graph
This is seen as a much friendlier way to store data and one that represents the real world. Data is stored and queried in a relationship-first approach. With the focus on representation, discoverability and maintainability. This type of database stores data on graph structures and uses nodes and edges to present and store the data.
Backends
There are multiple backends that you could choose from. From self hosting MySQL or Couch on your own servers, to hosting on a cloud service like Amazon AWS, to using a full Backend as a Service offering like Realm or Firebase, there are many, varied solutions. The key questions here are timing and skillset: if you want to get up and running fast, Firebase is a great solution. If you need total control but still want a cloud solution then AWS might suit you best. However, have you or your team used AWS before or do you have to learn?
As always, key to this is the relationship you have with your product development team. The discussion of database and backend is an important one, but it is one that will continue through the life of your app and is one that requires flexibility. Make sure to choose a well established company to work with and remember choosing the right tools starts with an understanding of the problem you are solving. As we always advise, understand the user, their problem and then the solution. Focus on the “why”. The rest we can solve with you!
