Yep. Not long ago I asked a dev why he had suddenly introduced Riak into the system.
'Because it's cool'
Oy.
'Because it's cool'
Oy.
"Let's rebuild something based on what the bulk of us already know," I suggested. (Keep in mind what we had was a few weeks of prototype code that was not in production.)
"No, I really want to learn more node," was the only other input, and that 'won' the decision. 18 months later... "yeah, koa isn't really a goof fit for our use cases".
C# is a great language, JVM is great w/ Kotlin/Clojure, both of those have tons of web servers.
And yes, per another point in the replies, someone else should have stepped in to decide differently when there was a tie. I could possibly have pushed harder, but the 'bozo bit' basically was flipped on that project, and much of what I lobbied for was ignored, at least in part because I was the one saying it.
Otherwise, it will grow into a monster that nobody want to deal with.
So... about 2 years later, there's some traction from folks to rebuild it in something else. The latest shiny object is AWS lambda.
It usually only takes me a minute or two to ask them a future function question that's not reasonably attainable (and performant) with a NoSQL solution... so they wind up going back to whatever RDBMS is their standard.
Of course you could solve that by having an ETL process dump your stuff into SQL (we keep our stuff in Cassandra and dump it into SQL for analysis), but that's another ETL you need to keep track of and in our case we use a quite complex data model and the ETL only supports a subset of it.
Another one just off the top of my head is joins. Some data is just inherently better suited in normal form.
Curious if you have an example of this.
It's not really a very nice way to go long term, but can be convenient when prototyping.
I think CouchDB had some real potential, but Mongo is like Couch without the interesting parts. Couch was like indexes on crack. You can make an index that does arbitrary transforms. Sad part was, it didn't have any smarts to pre-cache those "views" in an intelligent way, which to me would be the whole point of that endeavor. I think something like it will come back eventually, but it's still a very research-y idea.
As an aside, what I really wanted from CouchDB was that I could create a view and as I inserted new documents into the DB, CouchDB would automatically generate the new view documents so when I query the view, everything is already precached.
At the time I needed to implement a fire hose listener that would would sip inserts and decide which views with which parameters needed to get called, and then just hit them with REST to do the precaching. It seemed cumbersome, but it sort of made sense why it would be hard for the DB to know what queries on the view were implicated by a new document.
Has CouchBase improved the story there at all? To me that was always the killer promise of CouchDB... Storing documents in a format that made sense at creation time and having arbitrarily complex views on that data... without a cache hiccup. But that "without a cache hiccup" never seemed to quite materialize as a first class feature.