I haven't used RethinkDB in ages, but when I did, I used it exclusively for a year.
It took a few weeks for ReQL to really sink in, but once it did, I much preferred it to SQL. As my sibling comment says, its very linear: do this then this then this then this. It also feels very much like sequence processing in functional languages (and I was using Clojure at the time, so it really meshed very well).
I also found it much easier (than SQL, at least in my limited experience) to reason about performance because I knew what it was doing. Is this looked up by index? Yes, because that's the command I used.
So, yeah, ReQL actually ended up being one of the things I liked most about RethinkDB.
Especially the "known performance" bit. One of the things I fight with constantly in SQL Server is never getting consistent performance from a more complicated SQL query. The query plan could change from one day to the next if the plan falls out of cache.
With ReQL you new exactly how indexes were being used, and how the data was being accessed. No trying to guess what the query optimizer was doing in the background.
Exactly. I didn't appreciate this as much as I perhaps should have while working with RethinkDB, but I've been working on optimising SQL queries lately and... man I wish I were working in ReQL. It really made me appreciate how easy (compared to SQL) ReQL is to mentally estimate performance.
It took a few weeks for ReQL to really sink in, but once it did, I much preferred it to SQL. As my sibling comment says, its very linear: do this then this then this then this. It also feels very much like sequence processing in functional languages (and I was using Clojure at the time, so it really meshed very well).
I also found it much easier (than SQL, at least in my limited experience) to reason about performance because I knew what it was doing. Is this looked up by index? Yes, because that's the command I used.
So, yeah, ReQL actually ended up being one of the things I liked most about RethinkDB.