The key issue here is that SQLite runs as 'user' code, so if the user has access to the file, he can do whatever he wants to the file, and if the user doesn't have access to the file, he can't do anything. Yes, this has security implications, but it also has major efficiency implications. To get the sort of protection you seem to be wanting, you need to put the database behind some security wall which users have no access to, and provide an access API that limits what they can do with the system. This can be done in SQLite, but now the user program no longer is directly using SQLite, but your API that crosses that security barrier, into the 'server' application that is running, perhaps, SQLite. If that sort of thing is really part of your requirement, the simplest route may not be using SQLite, but some other database package inherently based on the more heavyweight client/server architecture, which can provide such protections.