Comment by jamiesonbecker | Hacker News Reader

Comment by jamiesonbecker | Hacker News Reader

Parent Full thread

SQL did win. Sorta.

NoSQL brought a lot of new ideas. Redis might seem superficially like NDB (MySQL Cluster), but underneath, it's extremely different. What kind of sane person could design a single-threaded, single process database? @antirez built something radical that delivers unbelievable performance.

More innovation and invention has happened in data in the last decade than in the previous thirty, and it's because people experimented and weren't afraid to fail.

Most NoSQL datastores swap limitations in one area for advances in another. Riak, Redis, DynamoDB.. S3 is probably one of the most successful examples of NoSQL, and its very limitations are crucial to its success. Each has clearly defined use cases.

Some people say "Big Data" or "NoSQL" when they really just mean Hadoop or MapReduce, but NoSQL just literally means "everything that's not SQL."

SQL is still great. Awesomeness like Postgresql's supporting every data type imaginable, Redshift and Aurora, file-based db's like SQLite...

So, yes, SQL won. But so did NoSQL. And all of the rest of us too.

I would say that people are too quick to jump on the new trend and are not evaluating what they actually need. In my company we are using PouchDB/CouchDb because of the exceptionally good sync engine, we have around 20 nodes offline at least 50% of the time, no SQL database could compete with PouchDB/CouchDb for this non-standard usecase, people should choose their DB according to what they need.

Same here, we're using CouchDB to get offline data on mobiles.

SQL, as a language, will always win. There is no more elegant way to work with sets, and you can't work with data without thinking about sets.

I really like his point about the original breakthrough of SQL being the ability to abstract the way the data is stored from the application, and the language was just a natural outgrowth.

SQL is actually a pretty terrible syntax, though. Relational algebra is beautiful and elegant, but SQL is a dated, '70s-y syntax on top of that.

how/why?

To the person who only knows SQL from feeding and care of servers, this seems like complaining about the color of a car that gets 1000 miles per gallon.

> There is no more elegant way to work with sets,

There are, but SQL is good enough and has so much inertia that its hard to see any alternative getting much traction.

(Its kind of like JS in the browser.)

The problem is people shoehorning relational problems into non relational databases. Then no one wins.

The same is true for the converse, as in both cases you get to be your own query planner and add client<->server latency on every join.

I wouldn't say it is as bad. Basically as you scale relational databases, you end up sharding and loose a lot of the relational features, and basically end up with NoSQL. In the majority of cases I see, people are not dealing with "big data" but think they are.

You can go really far with most relational database engines by adding hardware to a single instance instead of adding more instances.

> In the majority of cases I see, people are not dealing with "big data" but think they are.

Spot on. The amount of stuff you can do with a single $2,000 box these days is astounding.

Reply on news.ycombinator.com