We designed our documents just like separate tables and didn't want to denormalize the data model. This was a mistake and known anti-pattern for NoSQL, because we just can't easily join different documents together. It caused issues with updates (e.g., If I change the state of a meeting document that is linked to a number of other documents, then I need to fetch/update those separately) and all without a transaction, because CouchDB only ensures atomicity at the document level (& with bulk ops). It's far from intuitive, prone to error, and complex.

Certainly, having a classic RDBMS with an powerful ORM makes such operation much easier in practice, and safer as well.

I'm not bashing on NoSQL; we just use it badly and suffer from all the drawbacks while getting none of the benefits (since our schema is strict after all..).

CouchDB was appealing for offline-first because it exposes a RESTful API & means to replicate entire databases. So we had in mind to use PouchDB on the client-side; store a copy of the data locally while online, saving changes locally and synchronizing when going back online.

So it allows for a true offline-first approach, not a middle ground where you keep access to the subset of the data that you already got while browsing the app.

But it doesn't mean that it's easy, or that it ain't possible to do the same with a classic RDBMS, or a mix of tech...