[dingfeng_quek]

Besides multi-document transactions, I've encountered these problematic use-cases (something I discovered after scope creep of projects):

2. When I needed "more exotic" data types (e.g. but not limited to Decimals) where you want query/analytics logic to happen on the database rather than the app.

3. OLAP types of use cases. I really wanted collation, sort order, query optimizers, ability to "explore" the data in relational ways, and so on.

[arjunbajaj]

What did you use to solve these two use-cases?

[dingfeng_quek]

Couldn't figure out a way to solve them reasonably (and within schedule) using RethinkDB, so I did a "master-slave" with the RethinkDB as the master and PostgreSQL as a slave replica. Then did all the queries and analytics on the PostgreSQL database. I think this is far from ideal in terms of server costs, but scope creep is never ideal.

I suppose using computed property indexes in RethinkDB might work as well, or generating indexes, sort order, and doing query optimisation outside of the DB, but I couldn't figure it out in time, and it also seemed way more complicated than replicating the data to PostgreSQL.

EDIT: Above is for the OLAP use cases. OLAP of some types just don't go well with document databases. For the Decimal type, I stored it as a string, and had a computed property that transformed the string to a float. The float can then be indexed and queried like a number. It was good, until all the other OLAP use-cases creeped in.

Having said that, I found that custom replicas with RethinkDB is easy because it emits data change events. Never expected that feature to be an escape hatch.