3 ms·

This always happens and the noSQL market will eventually consolidate / settle down to a handful of players just as the SQL market did.

by blihp 8y ago

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.

This always happens and the noSQL market will eventually consolidate / settle down to a handful of players just as the SQL market did.

by 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.