The Differences Between MongoDB and SQLite

Mongo is the most widely known of all NoSQL databases, and an integral part of the JS-heavy MEAN stack. It’s popular with enterprise operations, particularly those with extremely high data requirements. It’s used by Facebook, Google, Adobe, Squarespace, and even banks like HSBC and Citigroup.

What’s it got going for it?

Well, firstly, it’s free and open-source, so if you’re on the fence, the cost of dipping your toes in is minimal. Secondly, it is extremely fast when dealing with high volumes of low-complexity data. The ideal use-case for Mongo is something like a weather station: it’s collecting multiple different data types every single second, but the data itself is fairly simple.

MongoDB is schemaless, which means it allows you to make any schema you like to fit your needs. This can be made easier by Mongoose ODM, which helps you model your application data, including built in validation, type casting, query building, and overall consolidates the amount of code you’d need to write.

This structure (combined with built-in sharding) does allow for a high degree of horizontal scalability and makes Mongo extremely flexible. On top of that, the JSON-like artifact storage allows it to store a much wider variety of data types than a traditional RDBMS, making it a better fit for databases that need to store more unusual types of data.

Totally on the opposite end of the spectrum, SQLite is a lightweight, serverless RDBMS, designed with economy and efficiency in mind, and is best suited for small-scale operations like individual apps or IoT devices. A lot of mobile apps run SQLite, and even the Android operating system uses it. It’s also used by a couple of core components of Windows 10 as well as the RedHat (RPM) package manager- which in addition to RedHat Linux is used in some popular Linux distributions like CentOS and Fedora.

SQLite supports having multiple DB users simultaneously, however it locks the whole database for both read and write operations, making it not suitable for large amounts of concurrent read/write operations. Though the delay is milliseconds per operation, a large amount of users makes this a problem.

If you’re coming from MySQL or another SQL DB, you’re going to have a much easier time adapting to SQLite: there’s almost no learning curve. It’s also serverless, which cuts down the mess even more—it goes directly to the database on disk. SQLite requires no admin and very little maintenance. This is what makes it perfect for home electronics and other systems where it’s difficult for the user to call in assistance.

When we talked about ideal use-cases for SQL databases, we used a hospital as an example. That would be great for MySQL, but might become an issue for SQLite. You’d more be looking at a personal website, an IoT device, or something like a Roomba that isn’t necessarily networked but has similar processing requirements to something like a smart fridge.

If you’re reading this, I’m going to take a wild guess that you are—at the very least—interested in databases, and maybe interested in going beyond that. If you’ve ever wondered what it takes to be a full-stack developer, this article will have you covered. If you want to do more than read, check out our careers page, we currently have openings for full stack web developer jobs.

  
But back to the issue on-hand: which database is the best, MongoDB or SQLite? Well, it varies wildly based on your intended use-case. Do you need a well or an ocean? Do you need a bicycle or a monster truck? Do you need a piece of toast or a twelve-course Vegas buffet? Sometimes you need to go all-out, but sometimes you just need something simple that does the job in front of you. Knowing how to make that choice is part of what makes a great developer.