Q:

SQLite Database vs. File based Data storage from Battery Performance Impact perspective

I have an app runs in a background service all the time (only when screen is on), and on a regular intervals (1-10 minutes) records a how long the interval time was and whether it was a good or bad interval. At the end of each day I take these counts of good and bad intervals and record it to a csv file.
For visual people like me:
           <--------------------------THE DAY --------------------->
minutes:    2m  1m    5m     3m    3m    3m    3m   1m  2m  1m  1m
          |----|---|-------|-----|-----|-----|-----|--|----|---|---|
              rec rec    rec   rec   rec   rec   rec rec  rec rec rec
       Record                                                     

Currently I use SharedPreferences to store the good/bad count throughout the day, and write it to a file at the end of the day, but am becoming increasingly worried about the persistence of the SharedPrefs data (I've had a few cases of it being wiped randomly by what I think was the OS clearing my apps cache)
I'm attempting to decide between recording these temporary counts in a File vs. migrating completely over to an SQLite database structure and making consistent calls to write and read throughout the day.
From a battery performance perspective, which is the least costly for making multiple writing and reading calls a day (~500-5000 actions) and Why?

A:

SQLite database == file based data storage
A SQLite database is just a mere file stored on disk, the performance difference will be minimal, the only thing a SQLite database does more is executing a little more instructions on the CPU to eventually get the data written.
The only reason why I wouldn't choose for a SQLite database is because maybe it's a little bit of overkill on the setup side since you're only writing numbers. What you could do instead is write a file yourself to the storage/sdcard and keep appending numbers to the file separated by newlines or some other CSV format.

