4 ms·

My aversion to NoSQLs is derived from the readiness with which uninformed people dive into them, integrate them with their products, and create a web of complex

My aversion to NoSQLs is derived from the readiness with which uninformed people dive into them, integrate them with their products, and create a web of complexity around something that should ideally be boring and reliable: the database. There are so many things that I've heard you "can't do in SQL" that are false, at least pertaining to Postgres. Semi-structured data, full-text search, "web scale" programming, geographical indexes... all of these things, people say "you can't do in a relational database" and that's not true. Postgres is fucking powerful and can do a lot, very well. Arguably, PostgreSQL isn't always a "relational database". You can use it as a key-value store. It just happens that you often want relational logic in a multi-purpose, long-lived data store. The relational database seems to be an attractor; the requirements that accrue to a typical in-house "we can do it better"/NIH non-relational database often converge on it. NoSQLs have their place at very large scale (100+ TB) and there are plenty of specialized reasons to use alternative databases-- I doubt that Postgres's full-text search is competitive with Elasticsearch-- but I feel like most of the anti-SQL sentiment is against the language. And sure, it's an ugly and outmoded language, but the database is one place where I'd rather have an ugly language and rock-solid tech than the other way around. Finally, fuck ORMs.

nawitus 12y ago
Note that just because something is possible with PostgreSQL doesn't mean it's as easy to do with PostgreSQL than with an alternative database. The question could be rephrased as "why use PostgreSQL when you can do it in x?".
Cakez0r 12y ago
Agree with all of your points. The thing that perhaps annoys me the most is that people seem to assume that nosql is magically fast and that sql is slow... Sure, a key-value pair lookup runs like shit off a shovel, but as soon as you want to run anything more complex than that, it's likely faster with a relational database and a few indexes... Usually the same people that think running an application on a cloud platform magically makes it fast, when in reality a VPS would be cheaper and faster.
- pkolaczk 12y ago
  NoSQL is not a well-defined term - there are huge differences between various solutions all commonly called "NoSQL", so the comparison to NoSQL is bogus. There are different NoSQL things designed with different use-cases in mind. On one side you'll have things like MongoDB, which is easy to set up, but doesn't really scale once your dataset grows out of memory, on the other side things like Cassandra which are unmatched by any RDBMS in terms of performance, scalability and availability on real-time, transactional workloads. Of course, your RDBMS of choice might be better at complex JOINs than Cassandra (which doesn't have JOINS at all, btw), but will it stand the chance at performace competition with Apache Spark or Hadoop? I don't think so.
curiously 12y ago
> Finally, fuck ORMs. Amen to that. Many times I wondered, geez I could've written this with a simple SQL query, here I am reading the docs.
nemothekid 12y ago
I think 100TB deployments is a very high bar you've set for postgres. I think the one place NoSQL databases continue to serve (and where My/Postgresql don't) are highly available, sharded deployments - and people are running into the issue at the 10s of TBs (I can't imagine you'd want 5TB+ of data served from a single node - AWS largest SSD instance would be 6.4TB in RAID0, and serving your database off a single large RAID0 already sounds like a bad idea). Not to say people aren't running these types of Postgres clusters, but its something not easily done. I think the anti-SQL sentiment is a very MongoDB-esque thing, in that MongoDB tried to replace everything. Most of the other popular NoSQL solutions have very clear and cut use cases, and are pretty upfront about selecting the right database.

nawitus 12y ago

Note that just because something is possible with PostgreSQL doesn't mean it's as easy to do with PostgreSQL than with an alternative database. The question could be rephrased as "why use PostgreSQL when you can do it in x?".

Cakez0r 12y ago

Agree with all of your points. The thing that perhaps annoys me the most is that people seem to assume that nosql is magically fast and that sql is slow... Sure, a key-value pair lookup runs like shit off a shovel, but as soon as you want to run anything more complex than that, it's likely faster with a relational database and a few indexes... Usually the same people that think running an application on a cloud platform magically makes it fast, when in reality a VPS would be cheaper and faster.

pkolaczk 12y ago
NoSQL is not a well-defined term - there are huge differences between various solutions all commonly called "NoSQL", so the comparison to NoSQL is bogus. There are different NoSQL things designed with different use-cases in mind. On one side you'll have things like MongoDB, which is easy to set up, but doesn't really scale once your dataset grows out of memory, on the other side things like Cassandra which are unmatched by any RDBMS in terms of performance, scalability and availability on real-time, transactional workloads. Of course, your RDBMS of choice might be better at complex JOINs than Cassandra (which doesn't have JOINS at all, btw), but will it stand the chance at performace competition with Apache Spark or Hadoop? I don't think so.

curiously 12y ago

> Finally, fuck ORMs. Amen to that. Many times I wondered, geez I could've written this with a simple SQL query, here I am reading the docs.

nemothekid 12y ago

I think 100TB deployments is a very high bar you've set for postgres. I think the one place NoSQL databases continue to serve (and where My/Postgresql don't) are highly available, sharded deployments - and people are running into the issue at the 10s of TBs (I can't imagine you'd want 5TB+ of data served from a single node - AWS largest SSD instance would be 6.4TB in RAID0, and serving your database off a single large RAID0 already sounds like a bad idea). Not to say people aren't running these types of Postgres clusters, but its something not easily done. I think the anti-SQL sentiment is a very MongoDB-esque thing, in that MongoDB tried to replace everything. Most of the other popular NoSQL solutions have very clear and cut use cases, and are pretty upfront about selecting the right database.