Hacker News Reader

Comment by gwbas1c | Hacker News Reader

> I must have missed the boat on this one. I remember in 2010 there was a brief period of time where NoSQL was in fashion, but it rightfully died pretty quickly to a small set of specialized use cases. There have been some cases where big data systems have replaced more traditional rdbms systems, but now you can use SQL for those too (like Hive SQL).

A few weeks ago I had a lead server-side architect call me up and ask if my client could tolerate eventual consistency. My answer was that "he could get away with that 10 years ago but that NoSQL went out of fashion and SQL came back in again."

To put it in a different context: Some people just go through periods in their life where they don't keep up and don't realize what was "new and exciting" 10 years ago turned out to be smoke and mirrors.

View on HN

What's the connection between NoSQL vs SQL and eventual consistency?

NoSQL in some cases trades off consistency for scalability (generally by sharding data, so propagating data across shards introduces eventual consistency).

As you can imagine, data that reside in a single shard don’t need to be propagated, so you can get strong consistency easily (e.g. fetching a single document). It’s when you start doing queries, joins, aggregations, etc. that you start encountering eventual consistency.

NoSQL is a bad name that really doesn't have anything to do with SQL per se, but is a shorthand for non-relational datastores (no one calls non-SQL relational systems “NoSQL”), which, while they depart from the relational model in a number of different ways, typically include eventual rather than strong consistency to support liveness in a distributed context.

Mainly that most people who ask that question are using it as a lead-in to promoting a NoSQL product.

NoSQL is very much alive and kicking, it’s just past the peak in the hype curve. There is a FAANG in particular who is notorious for banning relational databases outright because of their maintenance and scaling problems for their use cases.

As others have said, if you operate at a certain scale and can get away without complex joins and aggregations (which you should avoid anyway if you’re operating a high availability service), then NoSQL is a great option. It’s easier to scale out (often you just turn a knob) and its behavior is simpler and easier to predict.

What FAANG _bans_ relational DBs?

The phrase that comes out when someone proposes NoSQL is "we're not Google / Facebook."

Most applications don't need to run at "Google scale," thus they don't need the expense of relaxing ACID.

Of course, consider your use cases. There are good reasons to use NoSQL, and excellent reasons to use RDBMS. I use both professionally and appreciate the benefits of each.

Reply on news.ycombinator.com