So I agree with the article keep it simple and easy to implement, worry about scaling later.
'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.
I think this would be 10x more expensive to set up, manage, maintain and use than something like Riak.
Riak looks like it would be overpowered by my needs - but then again, I learn something new every day.
But then again, I could be super mistaken. I'm interested in seeing another side of it.
I am sure that for certain use cases, there are more tailored solutions, but "SQL + keystore" seems like a fairly universal, affordable and versatile stack.
Ignoring the difference for a minute. If you can fit data in Redis, chances are that they can fit in riak and a RDBMS is not needed at all.
Why Riak only then?
It is one of the very few databases that can be clustered. It is sharded, multi-master, highly available, to talk in buzzwords. It is very reliable and very robust, you can add/remove nodes as you wish, replication is highly configurable, etc...
Postgre/Mysql/MariaDB + Redis have no HA. They are both the disaster in disaster recovery.
1. Difficulty in transitioning a system with SQL-Gone-Wild to a system that can be implemented with other dbs without complexity overdrive 2. Escalating costs to get any additional availability guarantees out of SQL (availability & cost are key business issues)
In AWS & Google Cloud, you're going to need to pay outright for capacity as well as capacity devoted db recovery (a replica / set of replicas in another availability zone). On the other side with something like dynamo / cloud datastore, your payment model is based on requests / sec and the costs for replicated data. I'm just saying that there's nothing simple to deciding where price / availability / dev productivity balances will lead you to, and you can be an inexperienced developer who chooses either side of these technologies without really understanding the full story.
If you're inexperienced with relational databases, perhaps a Key-value store with a simple API is much simpler and easier to implement.