Pros and Cons of SQLite and Shared Preferences

It really depends on the data you want to store.

SQLite

Large amounts of same structured data should be stored in a SQLite database as databases are designed for this kind of data. As the data is structured and managed by the database, it can be queried to get a sub set of the data which matches certain criteria using a query language like SQL. This makes it possible to search in the data. Of course managing and searching large sets of data influences the performance so reading data from a database can be slower than reading data from SharedPreferences.

SharedPreferences

SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys.

This question has an accepted answer, but I think there is more to said on the topic - regarding speed.

An application's SharedPreferences and Sqlite DB are both just files, stored in the application's directories on the device's file system. If the amount of data is not too big, the Sqlite option will involve a larger and more complicated file with more processing overhead for simple access.

So, if the nature of the data does not dictate your choice (as explained in accepted answer), and speed matters, then you are probably better to use SharedPreferences.

And reading some data is often on the critical path to displaying the main activty so I think speed is often very important.

One final thought regarding speed and efficiency - if you need to use an Sqlite database for some structured data then it is probably more efficient to also store user preferences in the database so you are not opening a second file. This is a fairly minor consideration - probably worth consideration only if you need to access both the structured data and preferences before you can display the main activity.

My take is, it is not about speed or size but the kinds of operation you want to do to your data.

If you plan to do join, sort, and other DB operations on your data then go for Sqlite. An example is sorting data by date.

If you want to map simple values (like int, boolean, String) then use Preferences. DB operations won't work here and needless to say you need to have all the keys. An example is user password or app configuration.

The big temptation to embrace Preferences is when you want to use it to store a flattened POJO (a serialized JSON object) as String. Having such need is actually the sign to use Sqlite. Why ? Because complex data will eventually need complex oprations. Imagine retrieving a specific entry which could be handled by a simple "SELECT ... WHERE id = 1". In Preferences path, this will be a long process from deserializing to iterating the results.