Two of the more popular ‘Backend(s) As A Service’ for mobile apps are Parse and Firebase. I’ve used Parse in the past for other projects, and both are great ways to quickly bootstrap a database for a project. Both make user authentication incredibly easy. Both have relatively intuitive APIs, with Firebase potentially edging out Parse in terms of ease-of-use due to the Flutter plugins that have been created specifically for Firebase. In my opinion (pricing aside), the biggest difference between the two is that Firebase opts for a NoSQL data model, and Parse opts for a more traditional relational model. So what are the pro’s and cons of each?
If NoSQL is the new ‘hip’ thing, relational databases would probably be considered ‘classic.’ Intuitively, this model organizes data into relations (tables), which are grouped into an unordered collection of tuples (rows). Generally, they are most used in situations where the data naturally has some sort of regular structure– think sales or banking transactions, but they don’t have to be. Relational databases have been the most popular data model almost since its inception in the 1970’s.
One criticism of the relational model is the fact that in order to use the data in our application – we need some sort of intermediary framework to translate the tables and rows into the objects we use in our app. One common such framework is an Object-relational mapping framework like, say, SQLAlchemy used in Python-based web apps.
Another criticism of relational databases is that they don’t necessarily work well in situations where the data being queried tends to be a self-contained document, and tends to be queried as such most of the time. Depending on the application, an address could be an example of this scenario. In a relational database, addresses often represent a many to many relationship, necessitating at least three different tables: one table for the address itself with a foreign key to the intermediary table, one for the intermediary table with referenecs to the address table and user table, and one for the user table, again with a foreign key to the intermediary table. But does your app store user addresses and only query them along with the user as unit every single time? Or does it often want to run other queries on the address information– sorting all users who live in certain states, for example? The latter would be a better fit for the relational database that can run complex queries with many JOINs efficiently, but a relational database might not be the best fit for the former because it adds all this additional complexity without much tangible benefit.
NoSQL on the other hand can be organized in many different ways. Firebase specifically uses a documented-oriented database. So in contrast to relational databases- it tends to favor the former situtation in our example above- where addresses would be queried as self-contained documents, mostly. Additionally, there is no strict schema to adhere to, so designs that simply wouldn’t fit the relational model could be customized with the document model. As a result, in the right situation, NoSQL databases should scale better than relational.
The wrong situation for NoSQL databases would be those in which queries require many complex ‘JOINS’ (because support for joins is either weak or nonexistent in a document-oriented data model). Often, we’d have to create the ‘join’ in the application code itself, instead of utilizing the the optimizations that relational databases have for exactly that kind of query. Put another way- the document model works best in situations where we have lots of many-one relationships, and few many-many relationships.
These tradeoffs are worth considering when sitting down to think about the design of even personal projects, and more than once I’ve gotten the ‘why relational?’ or ‘why NoSQL?’ questions when discussing my personal projects with interviewers. Next week, I’ll discuss exactly the database design of our Meal Planner app and why the pros and cons of using NoSQL for it.
