Hacker News Reader

Comment by xrd | Hacker News Reader

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.

View on HN

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 :)

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.

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 :)

the ASF switched binary hosting providers, the COuchDB docs have the up to date links: https://docs.couchdb.org/en/stable/install/unix.html

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

E: typo

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/eNpTUNDW1dVWAAEgAwy0sXG0uRQUagLct...

Really depends on your use case. If that's the user's data anyway, no need to put it in an inner database.

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.

Reply on news.ycombinator.com