5 ms·

Slightly off the topic. In one of web applications (CRM alike) I was experimenting with SQLite-per-user approach. In that application user related data was clu

Slightly off the topic. In one of web applications (CRM alike) I was experimenting with SQLite-per-user approach. In that application user related data was clustered on per-user basis. So instead of single-db-for-all-users I had one-db-per-user. Performance gain was significant - around 25% for most of requests. I suspect that this is due the fact that index trees were significantly shorter for each particular user, data more local, etc. Yet db schema update and other batch requests can be made without stopping the server, just handle db files one by one. Just in case.

derefr 7y ago
The formalization of this approach is https://github.com/biokoda/actordb https://github.com/biokoda/actordb — which is essentially a sharded document store where one type of “document” is an SQL-addressable SQLite database. Sadly, ActorDB seems to be inactive as a project—but the fundamental premise is sound. I’d love to see the concept reimplemented as e.g. a Redis module (since a Redis cluster essentially has the same “shape” as ActorDB’s custom distributed K-V store.)
SiVal 7y ago
This is exactly the topic that made me read this thread. I have been wondering whether one sqlite file per customer was a good option for an online service where each customer needed only his own, private data but wanted to work on it from his desktop, laptop, or phone, with the option of occasionally downloading the file for additional backup. I just don't know enough about multi-tenant database approaches to know if this is a good idea or absurd, and I haven't found anyone talking about it. Any pointers to further insights would be greatly appreciated. Even a forum where (utterly unlike StackOverflow) I could ask such a question without already almost knowing the answer.
- carapace 7y ago
  SQLite in the browser... https://en.wikipedia.org/wiki/Web_SQL_Database https://en.wikipedia.org/wiki/Web_SQL_Database It was killed though. Derp.

derefr 7y ago

The formalization of this approach is https://github.com/biokoda/actordb https://github.com/biokoda/actordb — which is essentially a sharded document store where one type of “document” is an SQL-addressable SQLite database. Sadly, ActorDB seems to be inactive as a project—but the fundamental premise is sound. I’d love to see the concept reimplemented as e.g. a Redis module (since a Redis cluster essentially has the same “shape” as ActorDB’s custom distributed K-V store.)

SiVal 7y ago

This is exactly the topic that made me read this thread. I have been wondering whether one sqlite file per customer was a good option for an online service where each customer needed only his own, private data but wanted to work on it from his desktop, laptop, or phone, with the option of occasionally downloading the file for additional backup. I just don't know enough about multi-tenant database approaches to know if this is a good idea or absurd, and I haven't found anyone talking about it. Any pointers to further insights would be greatly appreciated. Even a forum where (utterly unlike StackOverflow) I could ask such a question without already almost knowing the answer.

carapace 7y ago
SQLite in the browser... https://en.wikipedia.org/wiki/Web_SQL_Database https://en.wikipedia.org/wiki/Web_SQL_Database It was killed though. Derp.