Thanks!

I've explained this a bit in the HN thread comments (https://news.ycombinator.com/item?id=25627081#25632696), but the choice of a NoSQL database was a mistake in our case. We did not model things the right way in the first place, and designed our documents in a relational manner, hoping to be able to later join documents together, which is not supported.

So, on the query side, we end up with difficulties for instance on list screens because we load documents of type X, which have a reference to documents of type Y, but we're unable to easily create a view that combines both so that we can search in those. But that's not the end of the world.

Another issue is the fact that when we perform updates on documents of type X, we often have to also update 1-n other documents of type A,B,C, but there are no transactions with CouchDB, meaning that we perform a cascade atomic, but separate updates, and if any of those fail, then we may end up with an invalid state. Not great.

It's all due to the way we designed our documents, so NoSQL is not at fault here, we just did it wrong, and understood it too late.

Next to that, since we make links between documents, those have to be kept in sync, but there are no foreign keys either, so if we're not careful, we can easily introduce incoherences (e.g., when deleting something).

And all of this adds up to the overall complexity; this is why I think that a classic RDBMS would've helped us a lot. We don't need to scale right now, and we've abandoned the idea of offline-first for now, so it's not useful at all for us. We know it, but switching would be really costly.