3 ms·
how do you handle things like encryption and access permissions? The only thing I have against using SQLite in production (for my needs) is the lack of at rest
by no_wizard 5y ago
how do you handle things like encryption and access permissions?
The only thing I have against using SQLite in production (for my needs) is the lack of at rest encryption and row level permissions by user.
- marcosdumay 5y agoAt rest encryption is a complicated subject (in general, I bet most people get negative net security from it). For SQLite, you can either encrypt your disk or get one of the versions with added encryption (I only know of proprietary ones). You don't do row level permissions on your database. You keep it all on the application layer.
- ttfkam 5y ago> You don't do row level permissions on your database. You keep it all on the application layer. You say this as some sort of objective truth. Keeping security about data at the data layer can often be a really good idea and just as appropriate as GRANT/REVOKE at the table and column levels.
- marcosdumay 5y agoWell, if you want to use SQLite, you keep it at the application layer. That's an objective truth. What is better, depends on what you are doing, and is not a simple choice in any way.
- ttfkam 5y agoThat's a tautology, isn't it? If the persistence engine you're using doesn't support a feature—no matter what that feature is—you'll have to fill in the shortfall somewhere else, such as the app layer. I'm just saying if you have the option, if the engine does support the feature, and the solution is a good fit for your problem, you shouldn't shy away from it just because some other engine doesn't support it.
- marcosdumay 5y agoHum, no. The word "tautology" doesn't mean that. Anyway, yes, SQLite lacks a series of features you get on other SGDBs, often for good reasons. In exchange it brings an entirely different set of features. If you want Postgres, use Postgres.