Some of my programs use SQLite. (In future I would consider to make something else based on avoiding what I think are many problems with SQLite, many of which would likely require to make an entirely different API; I will write about that later though, not right now.)

I made a ZZT editor which exposes virtual tables with the data of the ZZT world file, that you can use SQL for many kind of queries and batch operations, and SQL can also be used to customize the key bindings and macros.

I also have a NNTP server that uses SQLite, and a NNTP client that uses SQLite; in both cases, articles are stored in a SQLite database.

I also sometimes use SQLite command shell for querying and doing other data, too. (And, since Firefox stores bookmarks in a SQLite database, I also use a shell script involving SQLite to access the bookmarks from outside of Firefox.)

The "Free Hero Mesh" puzzle game engine uses SQLite in several ways:

• The per-user database stores the list of which levels you have solved, the list of moves you have made (including a mark that you may place in the move list), etc.

• Several virtual tables are exposed in order that the end user can query and do batch operations (in the level editor; some are read-only outside of the level editor).

• Although most key/mouse bindings will not need SQL, it is also possible to assign SQL to key/mouse bindings if you want more customization than the built-in features. (Even some of the default bindings do this, since some of them are easier to write in SQL than in C.)

• Some things, such as the picture loading and picture editor, internally use SQL queries with temporary tables for many things. For example, in one case it wants to find all combinations of picking one record from each of four groups, and a SQL query is used to find all such combinations (and to exclude some which are not needed).

• There is one "lazy table", used for the level listing screen (the end user can also use it, e.g. if you want to calcualte the percentage of solved levels). This is implemented as a eponymous-only virtual table, whose xOpen method will create a temporary table of the same name, fill it up, and then return SQLITE_SCHEMA, forcing it to recompile the query to access the temporary table instead. In some cases, the data becomes invalid, so it drops the table in this case, so that it will be reloaded in future. (See below for another note about dropping eponymous tables.)

(Note that the game rules engine of Free Hero Mesh does not use SQL at all, so an alternative implementation doesn't need to include any kind of SQL (and the program could be changed to not use SQL and the game will still work).)

If you are writing your own programs which use SQLite for whatever reason, then you might also consider some similar ideas than these, too.

(Note about dropping eponymous tables: Somehow, attempting to drop a eponymous virtual table seems to be slower than dropping a temporary table of the same name, and nothing happens if it is eponymous (other than wasting time). Do you know why it is slower in this case if it does nothing, than if it actually drops the table?)

So, the above includes some of the things listed in the "Appropriate Uses For SQLite" web page, but not all, and one thing not listed on that web page, but which is often useful, is to use SQLite to provide better capabilities for the end user to make customized queries, batch operations, etc.