Thanks for your support. The data is stored in a sqlite3 database. The next two big features will be network awareness (that is, you can have multiple databases sync with eachothers) and custom data fields where I was planning doing something like http://backchannel.org/blog/friendfeed-schemaless-mysql to get a fully customable configurations.

Instead of multiple databases in sync, why not use a real RDBM such as Postgres and have the clients sync to the master. The distributed databases-in-sync idea feels a bit like Git, which I love for code but would hate for production customer data. Those types of things need a canonical representation.

I single database would require a constant internet connection and would be much slower.

I aim for 0.1s feedback, and that's hard going over the network. See https://www.nngroup.com/articles/response-times-3-important-...

I don't think it's such a bad idea for production customer data. Actually I think it's a great idea and wrote my master thesis about that: http://fileadmin.cs.lth.se/cs/Personal/lars_bendix/Teaching/...

I would love to hear why you think it's a bad idea! Would you care to elaborate?

I definitely agree that you should continue to use sqlite as a local cache and read from it for initial display. But I believe that on save writing back to a central server and occasionally polling it for updates would provide many benefits, the most obvious of which is decoupling the UI from the data. See my reply to self in which I mentioned a possible HTTP interface.

To get a reasonable real world working application I believe I've to do something like that. Thanks =)

Reply to self. Another advantage of having a master database would be to allow rodent-dragging hipsters to write their own web client using a dozen Javascript libraries and get the latency that they would otherwise miss!