You are probably aware that there are seemingly endless options to consider when it comes to selecting a database and other technologies for your mobile app. With so many choices, it can be difficult and confusing to determine what really matters when it comes to your tech stack. A little while back, I wrote an extensive article on the different database architectures and use cases available to provide guidance on picking the right technology for the right project. While that is still an accurate and solid resource, this article takes a deeper dive into considerations for improving the performance of specifically mobile apps.
First and foremost, perhaps we should take a quick look at the difference between mobile and web apps. Mobile apps live and run on a mobile device itself, whereas web apps are accessed through a web browser and will adapt to whichever device you’re viewing them on. Native mobile apps are built for a specific platform, such as iOS for Apple or Android for, well, pretty much everything else. They are downloaded and installed through an app store and have access to system resources, such as GPS and the camera function. Web apps, however, are not native to a particular system and do not need to be downloaded or installed. Due to their responsive nature, they may look and function a lot like mobile apps, which is where some confusion arises.
To dig a bit deeper, mobile apps that are created for a targeted platform using the platform-specific SDK are categorized into Native Mobile Apps. Whereas Hybrid Mobile Apps are developed on platforms that provide code that is compatible with all available operating systems. Lastly, you may have heard of Progressive Web Apps (PWA’s), which many people claim is the future. With PWA’s, “The focus is towards creating web applications that have a look and feel exactly like native apps, without users having to download and install any software.”
While many companies may have incredible technology otherwise, their mobile apps often struggle with performance, latency, and/or connectivity issues. This can be due to numerous factors. Perhaps the organization did not put a lot of time or resources into building their mobile apps from the ground up, and therefore they do not stand on a solid foundation. Or maybe they are battling with latency issues due to centralized databases and cloud/vendor lock-in. Speaking of the database – is it equipped to handle the right amount of users and frequent updates? Does it store data offline or handle complex queries? These are all things to consider when building a new mobile app from scratch, or adding new features to an existing app, etc. Bear in mind that it’s not impossible (and actually with some technologies it’s quite easy) to migrate from one database to another if needed.
In my database architectures and use cases blog, I mentioned that when selecting a database, it’s important to consider your data type/structure, data volume, consistency, write & read frequency, hosting, cost, security, and integration constraints. While these certainly stand true, there are a few additional things you may want to consider when it comes to mobile apps:
- Support for multiple mobile app platforms
- Data synchronization
- Multi layer data model considerations
- Network connectivity
- Pushing new app updates and database changes
- Resolving data conflicts between devices
Clearly, there is a lot to consider here, and it can be quite overwhelming to figure out what type of database technology might be the best fit. For starters, some databases fit nicely into one category when it comes to data structure/type of functionality. Other technologies take more of a hybrid approach, enabling cross-functionality or combining the functionality of different tools into one. So, unless you have a very specific project or limited long-term goals, it might be best to go with a more flexible hybrid technology that encompasses more functionality into one package to reduce the number of systems needed.
Here I’ll try to provide a fair (while potentially still a little biased) explanation as to why HarperDB is the best option for improving the performance of your mobile app. From a high level, HarperDB is a modern hybrid database that combines the functionality of some of the best tools on the market into one, so it really covers a lot of bases. As a distributed database, it can be installed anywhere while presenting a single interface across a range of clouds, with backend ability to keep data synchronized everywhere. HarperDB is read and write optimized, handling upwards of 100K requests per second per node.
Of course, there are other great options out there as well. For example, this article published several years ago lists different database options based on functionality needed. HarperDB basically works everywhere in that table and provides all of the functionality mentioned.
Instead of trying to compare 300 different database options on the market, it might simplify your decision to do comparisons of this vs. that. This will enable you to take a deeper look at your needs and compare things like performance and cost. For example, in benchmark tests, HarperDB is 37 times faster than MongoDB and tends to be more cost-effective. It also supports SQL on JSON. Cockroach is a better fit for fintech use cases, whereas HarperDB may be a better fit for industries like gaming, ticketing, military, and media. You can’t lock out HarperDB’s database globally, and our clustering methodology relies on eventual consistency which allows for more efficient replication than more structured options. Relational databases like MySQL can be significantly more resource-intensive, requiring more maintenance and strict data structure. Whereas HarperDB can run on machines of all vertical scale from a Raspberry Pi to a supercomputer, requiring little to no maintenance, and with a dynamic schema allowing for easy data ingestion. This HarperDB vs. MongoDB vs. PostgreSQL comparison may be helpful as well.
Are you facing challenges around app latency? Or worried about being truly geo-distributed? With HarperDB, you can simply spin up more nodes to scale horizontally, putting HarperDB in various regions closer to your end-users, which will reduce latency and improve app performance, all while accessing data in real-time. By distributing APIs and data storage, and shifting application logic to the edge, you can remove bottlenecks and reduce infrastructure and cost. Globally replicating data at the speed of the Internet, HarperDB reduces app latency, improves performance and accessibility, and reduces overall complexity when it comes to data management. Lastly, HarperDB is about to release Custom Functions, which will enable developers to code their own custom API endpoints, utilizing core HarperDB methods, which results in a simplified tech stack and improved performance.
Mobile apps are constantly evolving, and you need a flexible database that can adjust on the fly without affecting performance. Even the most advanced and impressive technologies in the world will be brought down by a poor foundation or outdated database. Staying up to speed (literally) with modern technology is the best way to remain afloat in this highly competitive market. Therefore, the selection when it comes to your tech stack should not be taken lightly.