4 ms·

To be completely honest, I have never heard the term "NewSQL" before in my life. After a quick Google, it seems that the term basically means "SQL databases tha

To be completely honest, I have never heard the term "NewSQL" before in my life. After a quick Google, it seems that the term basically means "SQL databases that go FAST LIKE NOSQL." (Though it's not really popular.) Which is, once again, completely missing the point. I can't speak for professional devs - I'm just a hobbyist - but I'm not developing for "NoSQL" databases like CouchDB and Redis because I want to do SUPER WEB SCALE. I'm developing for CouchDB and Redis because they offer truly interesting alternative ways to look at your data. (In fact, Redis is what got me interested in data structures.) And if I wanted to write a project that used data that makes sense from a relational standpoint, SQLite (for development) and Postgres (for production) are just fine with me.

wmf 15y ago
OK, you're rational. Unfortunately you're in the minority.
jonpaul 15y ago
Exactly. I use MongoDB because schema-less databases make prototyping my applications easier. Migrations became a pain point.
pjscott 15y ago
There are a lot of people who would like a full-fledged relational database that scales up to large clusters. Just because you're not one of them doesn't mean they don't exist, or that they're "completely missing the point."
- LeafStorm 15y ago
  I was referring more to the marketing aspects of the term (and proposing their solution as a counterpart to "NoSQL"), than the concept itself. There are a lot of people who think that "NoSQL" is all about magic scaling sauce, and this isn't really helping.
  - nupark2 15y ago
    I don't really understand why one would accept the trade-offs of "NoSQL" if you aren't interested in "magic scaling sauce" (and clustered redundancy). What's the advantage here? Less rigorous schema, moving data modeling and constraints into the more complex application code that's much more likely to have bugs? I can't tell you how many times database constraints have caught application bugs with fatal data correctness consequences on the products we've worked on. The only reason I can see for abandoning those declarative constraints is because of the scalability issues one must contend with (and even then, I'm somewhat unconvinced that they matter for all but the highest-load entities).
    - pjscott 15y ago
      Some the the databases grouped under the over-broad NoSQL umbrella have reasons to use them other than magic scaling sauce. Redis, for example, is a ridiculously fast in-memory database that gives you data structures like sets, lists, hash tables, strings, numbers, and so on. It's tremendously useful for some problems. For example, at Greplin we're using Redis for our document analysis pipeline. We're pushing thousands of documents through Redis every second, using it to durably hold data while it gets passed around through our various back-end worker server clusters. We've been very happy with how Redis has been performing; it handles the write-heavy workload beautifully, and is way more resistant to data loss than most systems for doing this sort of thing. We'll be even happier when it gets server-side Lua scripting in a stable release, and we can define our own commands. The point is, though, that this would be crazy to do with a traditional SQL database, or even something like Riak or CouchDB or most of the other NoSQL databases. Redis fills a different niche, and filling a lot of cool niches is what I think the NoSQL stuff should be about.

wmf 15y ago

OK, you're rational. Unfortunately you're in the minority.

jonpaul 15y ago

Exactly. I use MongoDB because schema-less databases make prototyping my applications easier. Migrations became a pain point.

pjscott 15y ago

There are a lot of people who would like a full-fledged relational database that scales up to large clusters. Just because you're not one of them doesn't mean they don't exist, or that they're "completely missing the point."

LeafStorm 15y ago
I was referring more to the marketing aspects of the term (and proposing their solution as a counterpart to "NoSQL"), than the concept itself. There are a lot of people who think that "NoSQL" is all about magic scaling sauce, and this isn't really helping.
- nupark2 15y ago
  I don't really understand why one would accept the trade-offs of "NoSQL" if you aren't interested in "magic scaling sauce" (and clustered redundancy). What's the advantage here? Less rigorous schema, moving data modeling and constraints into the more complex application code that's much more likely to have bugs? I can't tell you how many times database constraints have caught application bugs with fatal data correctness consequences on the products we've worked on. The only reason I can see for abandoning those declarative constraints is because of the scalability issues one must contend with (and even then, I'm somewhat unconvinced that they matter for all but the highest-load entities).
  - pjscott 15y ago
    Some the the databases grouped under the over-broad NoSQL umbrella have reasons to use them other than magic scaling sauce. Redis, for example, is a ridiculously fast in-memory database that gives you data structures like sets, lists, hash tables, strings, numbers, and so on. It's tremendously useful for some problems. For example, at Greplin we're using Redis for our document analysis pipeline. We're pushing thousands of documents through Redis every second, using it to durably hold data while it gets passed around through our various back-end worker server clusters. We've been very happy with how Redis has been performing; it handles the write-heavy workload beautifully, and is way more resistant to data loss than most systems for doing this sort of thing. We'll be even happier when it gets server-side Lua scripting in a stable release, and we can define our own commands. The point is, though, that this would be crazy to do with a traditional SQL database, or even something like Riak or CouchDB or most of the other NoSQL databases. Redis fills a different niche, and filling a lot of cool niches is what I think the NoSQL stuff should be about.