Hacker News Reader

Comment by lacampbell | Hacker News Reader

Funny coincidence, I was actually reading the docs for it last night, and I am struggling to understand the lifetime of a local database.

From how I understand it, a local database will persist until the browser clears its cache. What happens in the situation where the cache clearing takes place while you are using the pouchdb database? Can that condition be handled?

I thought pouch might be a good fit for a web app you could use offline - you'd need connectivity to login or whatever, and sync the database initially. Then you'd modify the local one and sync it when it's all done, saving round trips to the server.

But that also raises the question - on the server side, is one database per user feasible? IIRC Couch can only handle 100 or so different databases on one instance. And you can't do views across them.

View on HN

(PouchDB contributor here.)

There are actually several layers of "cache" inside of a browser, including the traditional HTTP cache (which is global) as well as the site storage, which includes stuff like IndexedDB, WebSQL, LocalStorage, AppCache, and window.caches (all of which is per origin).

This site storage _can_ be cleared by the browser (it's "temporary" per the spec), but in practice it isn't very frequently cleared unless the machine is running low on space. E.g. Chrome only does it if a site exceeds 20% of total per-origin browser storage (https://developer.chrome.com/apps/offline_storage) whereas Edge is extremely conservative with clearing IDB because it's considered user data (e.g. email drafts in Outlook). In any case, when the browser does clear this storage, it clears everything at once for that origin, so the user essentially has the experience of visiting the site for the first time. This is why it's a good practice to periodically sync your PouchDB data to CouchDB because it can be lost in rare cases.

Also there is a new Storage spec that allows site authors to designate certain buckets of per-origin storage to be persistent, but this typically requires a user permission and isn't widely supported yet: https://storage.spec.whatwg.org/

I've been wondering the same. What would the alternative be? Sync between two pouchdb instances (one client and one server) and then sync the server-side pouchdb to couchdb?

Client side pouch happily syncs directly with server side couch

Right, but how do you scale that out on the server-side while protecting data on a per-user basis? Sorry if I'm missing something obvious.

I let the user decide to logout and destroy or just logout if it's a trusted device but obviously the local db could be accessed. Most users don't logout and I set a long cookie expiration.

You could also encrypt data.

Usually you create a separate database for every user.

This sounds _nuts_ from a traditional database mindset, but works great in Couch.

You can then create another database that replicates from all the user databases in order to perform your aggregate queries on the back end.

Seconded. This is the standard CouchDB approach: one database per user.

Sounds weird coming from my Postgres and MySQL background, but works great in practice, depending on your use case and if you clear out old revisions and unused docs, which for our use case can number into the thousands fairly rapidly.

> You can then create another database that replicates from all the user databases in order to perform your aggregate queries on the back end.

That sounds horribly space inefficent.

Yep.

Everything in software is a trade-off. This trades space efficiency for multi master replication with first class offline app experiences.

For many cases, that's a fine trade. Disks are cheap. If that isn't a fine trade for a particularly large dataset, use a different technology that's better at space efficiency and worse at other stuff.

Reply on news.ycombinator.com