<story><title>How NoSQL forced the evolution of a scalable relational database</title><url>http://blog.memsql.com/nosql/</url></story><parent_chain></parent_chain><comment><author>stickfigure</author><text>Everyone seems to want to compare against MongoDB, but when I think NoSQL I think about Google Cloud Datastore and Amazon DynamoDB. Databases which are fully hosted, infinitely scalable, zero-maintenance, transactional, reliable, and - at least with Google&amp;#x27;s offering - scales down to a free tier. They aren&amp;#x27;t perfect or applicable in every situation, but they&amp;#x27;re cheap and easy enough to allow a one- or two-programmer team to achieve massive scale without hiring devops.&lt;p&gt;MemSQL is so expensive you have to call for a quote.&lt;p&gt;If it&amp;#x27;s just &amp;quot;the ability to scale&amp;quot; then sure, SQL is back on the menu. MemSQL, Spanner, CockroachDB are leading the charge and that&amp;#x27;s great! But you have to pay a pretty penny for it (in TCO). There&amp;#x27;s still a lot of value in a cheap fire-and-forget scalable database, and there are not currently any SQL options there.&lt;p&gt;Regarding schemaless: I think this is a divide between people who work in dynamic languages vs people who work in statically typed languages. Schemaless databases are just fine in languages like Java; your classes define the schema with enough rigidity to keep you out of trouble. They wouldn&amp;#x27;t be my choice for Javascript though, that&amp;#x27;s for sure.</text></comment>
<story><title>How NoSQL forced the evolution of a scalable relational database</title><url>http://blog.memsql.com/nosql/</url></story><parent_chain></parent_chain><comment><author>antirez</author><text>Redis is not mentioned here at all so maybe the author is thinking mostly of other NoSQL software here, but well, in the case of Redis the whole point was not just the in-memory performance part, but the data model as well. My claim is that you can&amp;#x27;t really exploit the advantage of using memory if you perpetuate in using the memory to represent the same data model that you were using with relational databases. For instance think at Redis sorted sets in the use case of leaderboards in popular games (the same pattern is used in a number of applications that have nothing to do with games). To use SQL, even an in memory one, in such use case is not going to work. So in the case of Redis the point was to remove the interface between the user and the way the data is actually fetched from data structures, to make the user do the choices in a very direct way. Thus this article does not apply to Redis in my opinion. I&amp;#x27;ve the feeling that many other NoSQL products could argument like that, but in other areas of their research and difference. For instance I&amp;#x27;ve issues to see how modern SQL systems can replace CRDTs based stores.</text></comment>