5 ms·

There are places where relational DBs are inherently better than noSQL (namely when you need fully up-to-date information on every query, no matter what) - But

There are places where relational DBs are inherently better than noSQL (namely when you need fully up-to-date information on every query, no matter what) - But those situations are becoming more rare compared to situations where potentially stale data is an okay tradeoff for performance gains. Honestly, IMO the biggest issue holding noSQL databases back is lack of good documentation/support a lot of the time. Technically, though, they're going to become the standard for most use cases soon.

lykr0n 8y ago
The problem with noSQL is that there are too many players out there making duplicated efforts. You have MySQL & MariaDB and PostgreSQL as the two main SQL platforms, but you have too may to list in the noSQL field- most of them providing the same amount of functionality.
- blihp 8y ago
  This always happens and the noSQL market will eventually consolidate / settle down to a handful of players just as the SQL market did.
  - DaiPlusPlus 8y ago
    That depends on the functionality requirements of noSQL customers. I posit that writing a new, indepedent RDBMS that implements the latest SQL spec with the same maganement and replication capabilities as the incumbents is on-par with trying to compete with WebKit and Gecko. The SQL Server engineering team at Microsoft is about 1,000 people according to my friends on campus. Whereas implementing a Key-Value Store is orders of magnitude simpler. There is plenty of room for innovation, of course - but you don’t need 1,000 people to build-on some new replication scheme or distributed backend. If you take a simple NoSQL system then tack on things like object scheme support, JSON blob value indexes, node graph support, etc you’ll end up with an RDBMS analogue. So the barrier-to-entry to building a NoSQL system is much lower than a RDBMS - and for many companies they might decide to build their own rather than extend an existing system - leading to more completion but not necessarily a better product.
    - blihp 8y ago
      It always starts that way. In time, the legacy baggage that gets added will turn the noSQL databases into the same bloated monsters that the SQL databases have become. There was a time when many of the SQL database options were the (relatively) simpler and more powerful options vs the wide variety of home-grown databases they eventually replaced. (i.e. there was a lot of baked in business logic etc. that the move to SQL databases forced companies to disentangle from the database engine itself) SQL Server was originally just a fork of Sybase SQL Server (a much smaller, simpler version) with some FoxPro tech bolted on to it...
      - DaiPlusPlus 8y ago
        Right - and FoxPro was just another dBase clone. NoSQL today is where dBase was 30 years ago.
      - natmaka 8y ago
        A famous P. Greenspun quote may be savagely hacked for the topic at hand: Any sufficiently complicated No/New/WhateverSQL engine contains an ad hoc, informally-specified, bug-ridden, slow implementation of a RDBMS.
    - sjellis 8y ago
      > That depends on the functionality requirements of noSQL customers. I posit that writing a new, indepedent RDBMS that implements the latest SQL spec with the same maganement and replication capabilities as the incumbents is on-par with trying to compete with WebKit and Gecko. The SQL Server engineering team at Microsoft is about 1,000 people according to my friends on campus. CockroachDB is the newest from-scratch SQL engine that I am aware of: https://www.cockroachlabs.com/ https://www.cockroachlabs.com/ They re-use the RocksDB K/V store maintained by Facebook (in C++) as the storage layer, and their own code is written in Go, so I suspect that their development work is probably a lot less time-expensive than the teams working on older SQL databases.
- scarface74 8y ago
  Are you forgetting about SQL Server and Oracle?
  - icebraining 8y ago
    And SQLite!
    - AznHisoka 8y ago
      and Sybase and ComDB...
- Spooky23 8y ago
  That’s what happens in a growing market. Once it’s matured, it boils down to a handful.
- hodgesrm 8y ago
  > You have MySQL & MariaDB and PostgreSQL as the two main SQL platforms Based on license revenue it's actually Oracle and MS SQL server by miles. They are currently #1 and #3 on DB-Engines.com. (https://db-engines.com/en/ranking https://db-engines.com/en/ranking) MySQL is #2. PostgreSQL is #4, though it's pretty far back from the first three.
  - marcolussetti 8y ago
    Maybe I'm confused, but ranking databases on license revenue will inevitably show that the databases that charge licenses are higher. I mean PostgreSQL is open source, and required no license fee. I'm not sure that license revenue is a good comparison metric.
    - hodgesrm 8y ago
      DBMS Engines uses a set of metrics that does not include revenue. See https://db-engines.com/en/ranking_definition https://db-engines.com/en/ranking_definition for more. Oracle and MS SQL Server have consistently ranked highly there for many years.
  - killbrad 8y ago
    You know MySQL, MariaDB, and Postgres don't have licensing costs, right?
    - hodgesrm 8y ago
      Of course. I've worked in and around the OSS DBMS market for over a decade. But the numbers were really big. It seems to me that out of a 2015 US $30B DBMS market Oracle and MS were collecting something like US $29B. The rest of the market,which included products like MongoDB and Cassandra was close to a rounding error. (I don't have the Gartner report handy, sorry.) It's popular on HN to focus on OSS products, but there's a very large proprietary RDBMS market measured both in terms of revenue as well as users. That's how Oracle and MS got to be the behemoths they are today.
just_myles 8y ago
Agreed. I think for temporal data (accounting) reporting non-relational databases are fine.
- just_myles 8y ago
  To clarify further. Of course, you will need a relational data repository.
jefftk 8y ago
> when you need fully up-to-date information on every query, no matter what This doesn't require something relational, just something centralized. And not even that; consider Spanner.
amf12 8y ago
> namely when you need fully up-to-date information on every query, no matter what So you basically want full consistency (vs eventual consistency) in a distributed environment. You can set up you noSQL that way. I don't see how relational DB's are "better" than noSQL in consistency.
- ric2b 8y ago
  And if you do that you go back to the performance of one instance or (probably) worse.
  - amf12 8y ago
    Absolutely, but isn't that the case for SQL too? My point being, noSQL is not worse than SQL if all you care about is storing and retrieving documents vs joins, etc.
threeseed 8y ago
Why do people continue to use the term NoSQL ? It's ridiculous. There are hundreds maybe thousands of NoSQL databases ranging from Redis to MongoDB to Cassandra to InfluxDB to Druid. They pretty much have nothing in common other than storing data. Many of them support SQL directly, others via Spark and almost all have a SQL equivalent.
- endymi0n 8y ago
  Exactly this, „non-traditional“ and noSQL is as inexact as it gets. It includes an incredibly wide range of architectures, from Spanner and CockroachDB which deliver ACID guarantees equal and even surpassing relational systems to pure performance tuned systems such as Aerospike which have few guarantees and features but are blazingly fast. There are pretty much all shades of consistency in between, like Cassandra and Scylla with tunable consistency amd LWT. Lumping them all together into a single category will yield poor results.

lykr0n 8y ago

The problem with noSQL is that there are too many players out there making duplicated efforts. You have MySQL & MariaDB and PostgreSQL as the two main SQL platforms, but you have too may to list in the noSQL field- most of them providing the same amount of functionality.

blihp 8y ago
This always happens and the noSQL market will eventually consolidate / settle down to a handful of players just as the SQL market did.
- DaiPlusPlus 8y ago
  That depends on the functionality requirements of noSQL customers. I posit that writing a new, indepedent RDBMS that implements the latest SQL spec with the same maganement and replication capabilities as the incumbents is on-par with trying to compete with WebKit and Gecko. The SQL Server engineering team at Microsoft is about 1,000 people according to my friends on campus. Whereas implementing a Key-Value Store is orders of magnitude simpler. There is plenty of room for innovation, of course - but you don’t need 1,000 people to build-on some new replication scheme or distributed backend. If you take a simple NoSQL system then tack on things like object scheme support, JSON blob value indexes, node graph support, etc you’ll end up with an RDBMS analogue. So the barrier-to-entry to building a NoSQL system is much lower than a RDBMS - and for many companies they might decide to build their own rather than extend an existing system - leading to more completion but not necessarily a better product.
  - blihp 8y ago
    It always starts that way. In time, the legacy baggage that gets added will turn the noSQL databases into the same bloated monsters that the SQL databases have become. There was a time when many of the SQL database options were the (relatively) simpler and more powerful options vs the wide variety of home-grown databases they eventually replaced. (i.e. there was a lot of baked in business logic etc. that the move to SQL databases forced companies to disentangle from the database engine itself) SQL Server was originally just a fork of Sybase SQL Server (a much smaller, simpler version) with some FoxPro tech bolted on to it...
    - DaiPlusPlus 8y ago
      Right - and FoxPro was just another dBase clone. NoSQL today is where dBase was 30 years ago.
    - natmaka 8y ago
      A famous P. Greenspun quote may be savagely hacked for the topic at hand: Any sufficiently complicated No/New/WhateverSQL engine contains an ad hoc, informally-specified, bug-ridden, slow implementation of a RDBMS.
  - sjellis 8y ago
    > That depends on the functionality requirements of noSQL customers. I posit that writing a new, indepedent RDBMS that implements the latest SQL spec with the same maganement and replication capabilities as the incumbents is on-par with trying to compete with WebKit and Gecko. The SQL Server engineering team at Microsoft is about 1,000 people according to my friends on campus. CockroachDB is the newest from-scratch SQL engine that I am aware of: https://www.cockroachlabs.com/ https://www.cockroachlabs.com/ They re-use the RocksDB K/V store maintained by Facebook (in C++) as the storage layer, and their own code is written in Go, so I suspect that their development work is probably a lot less time-expensive than the teams working on older SQL databases.
scarface74 8y ago
Are you forgetting about SQL Server and Oracle?
- icebraining 8y ago
  And SQLite!
  - AznHisoka 8y ago
    and Sybase and ComDB...
Spooky23 8y ago
That’s what happens in a growing market. Once it’s matured, it boils down to a handful.
hodgesrm 8y ago
> You have MySQL & MariaDB and PostgreSQL as the two main SQL platforms Based on license revenue it's actually Oracle and MS SQL server by miles. They are currently #1 and #3 on DB-Engines.com. (https://db-engines.com/en/ranking https://db-engines.com/en/ranking) MySQL is #2. PostgreSQL is #4, though it's pretty far back from the first three.
- marcolussetti 8y ago
  Maybe I'm confused, but ranking databases on license revenue will inevitably show that the databases that charge licenses are higher. I mean PostgreSQL is open source, and required no license fee. I'm not sure that license revenue is a good comparison metric.
  - hodgesrm 8y ago
    DBMS Engines uses a set of metrics that does not include revenue. See https://db-engines.com/en/ranking_definition https://db-engines.com/en/ranking_definition for more. Oracle and MS SQL Server have consistently ranked highly there for many years.
- killbrad 8y ago
  You know MySQL, MariaDB, and Postgres don't have licensing costs, right?
  - hodgesrm 8y ago
    Of course. I've worked in and around the OSS DBMS market for over a decade. But the numbers were really big. It seems to me that out of a 2015 US $30B DBMS market Oracle and MS were collecting something like US $29B. The rest of the market,which included products like MongoDB and Cassandra was close to a rounding error. (I don't have the Gartner report handy, sorry.) It's popular on HN to focus on OSS products, but there's a very large proprietary RDBMS market measured both in terms of revenue as well as users. That's how Oracle and MS got to be the behemoths they are today.

just_myles 8y ago

Agreed. I think for temporal data (accounting) reporting non-relational databases are fine.

just_myles 8y ago
To clarify further. Of course, you will need a relational data repository.

jefftk 8y ago

> when you need fully up-to-date information on every query, no matter what This doesn't require something relational, just something centralized. And not even that; consider Spanner.

amf12 8y ago

> namely when you need fully up-to-date information on every query, no matter what So you basically want full consistency (vs eventual consistency) in a distributed environment. You can set up you noSQL that way. I don't see how relational DB's are "better" than noSQL in consistency.

ric2b 8y ago
And if you do that you go back to the performance of one instance or (probably) worse.
- amf12 8y ago
  Absolutely, but isn't that the case for SQL too? My point being, noSQL is not worse than SQL if all you care about is storing and retrieving documents vs joins, etc.

threeseed 8y ago

Why do people continue to use the term NoSQL ? It's ridiculous. There are hundreds maybe thousands of NoSQL databases ranging from Redis to MongoDB to Cassandra to InfluxDB to Druid. They pretty much have nothing in common other than storing data. Many of them support SQL directly, others via Spark and almost all have a SQL equivalent.

endymi0n 8y ago
Exactly this, „non-traditional“ and noSQL is as inexact as it gets. It includes an incredibly wide range of architectures, from Spanner and CockroachDB which deliver ACID guarantees equal and even surpassing relational systems to pure performance tuned systems such as Aerospike which have few guarantees and features but are blazingly fast. There are pretty much all shades of consistency in between, like Cassandra and Scylla with tunable consistency amd LWT. Lumping them all together into a single category will yield poor results.