I don't understand what background application you're referring to. If I have an app that reads and writes to a bunch of CSV files how is that any different from using libsqlite3 to read and write to an sqlite file?
Imagine if you will that database projects do exist, but don't come with easy to deploy documentation. What you have is stuff in source code tarballs and a vague idea of what dependencies you will need and what versions. You can't just `apt-get install mysql-server` and be done. You have to compile the stuff from scratch. Download a tarball, run `./configure && make`, wait ten minutes, come back to see that some dependency wasn't met, download that, `./configure && make` that, find yet another dependency. And this in some cases is the superior method to the RPM hell you might encounter. Oh and don't forget to supply all the necessary configuration flags to get the features you need, or else you won't be able to use the thing you just installed.
If all you want to do is run a small project, or a big one where performance matters and you have deadlines, you might just "do it by hand" and simply create your own pseudo-database out of flat files, memory dumps, whatever.
I meant RDBMSes that are not SQLite. For MySQL or Postgres or whatever you usually need to do a system-wide package install and have a daemon running in the background. Portability of (compiled version of) your program disappears. That's why desktop apps - games in particular - tend not to use any database other than SQLite or flat file structure.
