Similar to what we did in the previous chapter, let's look at why we choose the tools that we use. Our requirements for choosing a database are as follows:

• The solution should be portable
• Ease of installation and learning--we want to get up and running as fast as possible
• Compatible with the Raspberry Pi
• Lightweight since we are running it on our Pi with limited resources
• Feature-rich enough to support the requirements of our application

SQLite is one such database that fits these requirements quite well:

• Portability: SQLite can be run almost anywhere, with minimal dependencies. The only thing that SQLite relies on to maintain all your data is a single file on your system. What this means when you want to transfer your entire database to another machine is that the only thing you have to give them is the database file that your SQLite instance was using.
• Lightweight and ease of use: SQLite does not have any other dependencies, unlike most other databases. Just ask anyone who has ever installed MySQL. There is a single binary, which you run while specifying which file to use and get going.
• Standards compliant: SQLite uses the SQL database query language and consequently comes along with its rich features. It's like getting all the features of modern feature-rich relational databases with none of the overhead of configuration and set up.

Of course, there is no such thing as a silver bullet. SQLite has all these great features as a trade-off for other commonly used features:

• No user management: There is no provision for managing users and their rights to different databases. SQLite cannot be used with a multi-user application where access to each database must be fine-tuned.
• Limited write operations: SQLite allows only one write operation to take place at any time, so anything related to concurrency gets thrown out of the window.

The application we are building, however, is not affected by any of these limitations because:

• There is only one user, that is, our server application. All the regular users of our application do not directly access our database; they only do it through the server.
• We do not have high volume write operations. The purpose of having persistent storage is that we can record the readings as and when they are captured. This happens once every 2 seconds, and so we do not have to think about high volumes in this case.

For these reasons, the SQLite database is the best-suited choice for our use case.