5 ms·

Do you use «one database per user» model or «all users data in one db» model?

by goohle 5y ago

xrd 5y ago
One database per user. And even disregarding the obvious inability to natively join information across tables, it still was a mess to subscribe to changes across all of them and all the other things you take for granted with a relational database. And to me, it looks like couchdb is on life support as a technology. It's a great idea and revolutionary in it's time, putting everything as documents with views, etc. But, too many gaps and unclear direction.
- janl 5y ago
  CouchDB dev here, I can confirm that CouchDB is very much not on life support. Active work goes into PouchDB and CouchDB, some of which is addressing the issues brought up here. Nothing shipping yet (aside from maybe native jwt auth in this months 3.2.0 release), but definitely ongoing :)
  - xrd 5y ago
    That's great to hear. I love PouchDB for the record. It's amazing. That's really great to hear about native JWT auth support, that is a huge gap for me to not have a good story of how to do auth. I totally understand the reasons for moving it outside of the database, but it was too much work to create and manage my own proxy on top of couchdb. Thanks a lot for the clarification, and I'll be watching.
  - BackBlast 5y ago
    Glad to hear a new release is coming. I run CouchDB in production. I have actually checked the couchdb repo to see if it was being maintained. Some of the things that trouble me. The ubuntu upstream package manager dropped off the radar for a while, not sure if it's currently running or not. Also, the last release was a looong time ago. I understand it's pretty stable, but there are rough spots that could use some shoring up as noted. These issues aren't enough for me drop its active use in production, but I'm eyeing reworking how I use if these kinds of issues continue. This kind of dropping the ball doesn't instill confidence. I don't want to have to maintain my own installer so I can predictably perform new installations. Also, no Linux ARM package. I gave a go at compiling it myself for ARM, but that failed due to being unable to find/use a compatible SpiderMonkey. It's great tech, and I'd love to carry it with me into bigger and better projects. Here hoping :)
    - janl 5y ago
      the ASF switched binary hosting providers, the COuchDB docs have the up to date links: https://docs.couchdb.org/en/stable/install/unix.html https://docs.couchdb.org/en/stable/install/unix.html
- lytefm 5y ago
  Jan has actually been working on per-document access control and according to the discussion it is expected to land in CouchDB 4 [1]. CouchDB doesn't move extremely fast. It's kinda boring and reliable once everything is set up - which I consider a good thing. But I agree, it's annoying to not be able to analyse data across multiple user DBs with a single query or to build hacky solutions when listening to changes across databases. [1] https://github.com/apache/couchdb/issues/1524 https://github.com/apache/couchdb/issues/1524 E: typo
- goohle 5y ago
  IMHO, user databases (both CouchDB and PouchDB) are just front cache. User can mess with his data in CouchDB/PouchDB using API, so it's important to keep data in an inner database, inaccessible to user, and copy data between databases. Inner database can be a SQL database, e.g. PG with jsonb. +--+ +-------+ +-------+ +--+ |PG+<-+->+CouchDB+<-->+PouchDB+<-->+UI| +--+ | +-------+ +-------+ +--+ | +->... | +->... [0]: https://kroki.io/ditaa/svg/eNpTUNDW1dVWAAEgAwy0sXG0uRQUagLctW10tXXttJ3zS5MzXJyAPCAnAJkT6lnDpQA1s4YIMyGgBs4Cmq6np4dbAgB3lR-y https://kroki.io/ditaa/svg/eNpTUNDW1dVWAAEgAwy0sXG0uRQUagLct...
  - BackBlast 5y ago
    Really depends on your use case. If that's the user's data anyway, no need to put it in an inner database.
- dynamite-ready 5y ago
  I've actually been using Couch DB with Pouch directly to authenticate users on a small app, with a DB per user. Tbf, my app isn't all that large or complex at this stage, so I don't know if there's any overlap in what we're doing. But from your post, relational joins aside, I can't understand what's breaking for you specifically. You're offering nebulous gripes tbf, not discrete problems.

Do you use «one database per user» model or «all users data in one db» model?

by goohle 5y ago

Do you use «one database per user» model or «all users data in one db» model?

xrd 5y ago

One database per user. And even disregarding the obvious inability to natively join information across tables, it still was a mess to subscribe to changes across all of them and all the other things you take for granted with a relational database. And to me, it looks like couchdb is on life support as a technology. It's a great idea and revolutionary in it's time, putting everything as documents with views, etc. But, too many gaps and unclear direction.

janl 5y ago
CouchDB dev here, I can confirm that CouchDB is very much not on life support. Active work goes into PouchDB and CouchDB, some of which is addressing the issues brought up here. Nothing shipping yet (aside from maybe native jwt auth in this months 3.2.0 release), but definitely ongoing :)
- xrd 5y ago
  That's great to hear. I love PouchDB for the record. It's amazing. That's really great to hear about native JWT auth support, that is a huge gap for me to not have a good story of how to do auth. I totally understand the reasons for moving it outside of the database, but it was too much work to create and manage my own proxy on top of couchdb. Thanks a lot for the clarification, and I'll be watching.
- BackBlast 5y ago
  Glad to hear a new release is coming. I run CouchDB in production. I have actually checked the couchdb repo to see if it was being maintained. Some of the things that trouble me. The ubuntu upstream package manager dropped off the radar for a while, not sure if it's currently running or not. Also, the last release was a looong time ago. I understand it's pretty stable, but there are rough spots that could use some shoring up as noted. These issues aren't enough for me drop its active use in production, but I'm eyeing reworking how I use if these kinds of issues continue. This kind of dropping the ball doesn't instill confidence. I don't want to have to maintain my own installer so I can predictably perform new installations. Also, no Linux ARM package. I gave a go at compiling it myself for ARM, but that failed due to being unable to find/use a compatible SpiderMonkey. It's great tech, and I'd love to carry it with me into bigger and better projects. Here hoping :)
  - janl 5y ago
    the ASF switched binary hosting providers, the COuchDB docs have the up to date links: https://docs.couchdb.org/en/stable/install/unix.html https://docs.couchdb.org/en/stable/install/unix.html
lytefm 5y ago
Jan has actually been working on per-document access control and according to the discussion it is expected to land in CouchDB 4 [1]. CouchDB doesn't move extremely fast. It's kinda boring and reliable once everything is set up - which I consider a good thing. But I agree, it's annoying to not be able to analyse data across multiple user DBs with a single query or to build hacky solutions when listening to changes across databases. [1] https://github.com/apache/couchdb/issues/1524 https://github.com/apache/couchdb/issues/1524 E: typo
goohle 5y ago
IMHO, user databases (both CouchDB and PouchDB) are just front cache. User can mess with his data in CouchDB/PouchDB using API, so it's important to keep data in an inner database, inaccessible to user, and copy data between databases. Inner database can be a SQL database, e.g. PG with jsonb. +--+ +-------+ +-------+ +--+ |PG+<-+->+CouchDB+<-->+PouchDB+<-->+UI| +--+ | +-------+ +-------+ +--+ | +->... | +->... [0]: https://kroki.io/ditaa/svg/eNpTUNDW1dVWAAEgAwy0sXG0uRQUagLctW10tXXttJ3zS5MzXJyAPCAnAJkT6lnDpQA1s4YIMyGgBs4Cmq6np4dbAgB3lR-y https://kroki.io/ditaa/svg/eNpTUNDW1dVWAAEgAwy0sXG0uRQUagLct...
- BackBlast 5y ago
  Really depends on your use case. If that's the user's data anyway, no need to put it in an inner database.
dynamite-ready 5y ago
I've actually been using Couch DB with Pouch directly to authenticate users on a small app, with a DB per user. Tbf, my app isn't all that large or complex at this stage, so I don't know if there's any overlap in what we're doing. But from your post, relational joins aside, I can't understand what's breaking for you specifically. You're offering nebulous gripes tbf, not discrete problems.