Hacker News Reader

Comment by memracom | Hacker News Reader

Lets just say that PostgreSQL answers the criticisms of relational databases that led to NoSQL. The complaints all boiled down to saying that the RDBMS forced you to do things one way and that it was cumbersome. PostgreSQL evolved and fixed the most annoying issues like JSON support and schemaless key-value store support. That's the way open source is supposed to work. Now folks are learning that throwing out the baby with the bathwater leads to more complexity than just learning how to use a relational database. The pendulum has swung back.

View on HN

> PostgreSQL evolved and fixed the most annoying issues like JSON support and schemaless key-value store support.

As I recall, automatic sharding was on that list, and pg doesn't attempt to tackle that afaik.

Mongo doesn't really do that in a way you can reliably use in practice either, though. Its sharding offers a subset of operations over an inconsistent view of your dbs.

You can do that with Postgres trivially, and even automatically with postgres_fdw and writeable views.

This story has played out before. Last time, it was Object Oriented databases. What happens each time is that the traditional RDBMS's pick up a few of the features, and then we keep using them until the next contender comes along.

This is not true at all. The actual realization the past years is that strictly enforced relationality (is that a word?) and transactions are constructs that are not always or even rarely actually needed. Eventual consistency, schemaless data modelling and so on picked up steam and for good reasons. Every technology that survives the "Oh, new toy!" stage has a place or it wouldn't still exist. It is up to developers to choose the appropriate technology for them and their projects. That isn't to say that a lot of persistence problems cannot be solved by an RDBMS, a k/v store and a document store. In that case just base your decision on other drivers (comfort level, cost, and so on)

> Eventual consistency,

...may be possible, but almost always requires domain-specific concurrency-level understanding in your datastore, and is almost always harder to work with than strong consistency.

Saying that transactions are 'rarely' needed boggles my mind. Working inside transactions (where feasible, which is in the large majority of situations) vastly simplifies data storage.

Agreed. The first rule of computing is that anything can do everything -- it's just a matter of how challenging it is to implement.

The notion of transactions were invented not for performance, but because they are easier to reason about. So much easier that it often means the difference between a project that never finishes and a project that finishes so early that you have time to spend on optimization and caching.

PostgreSQL doesn't answer the criticisms of relational databases.

It is still cumbersome to use, hard to shard, even harder to cluster and is incredibly complex to manage compared to databases like Cassandra.

You had me until the "like Cassandra" bit ;) If there's one thing where Cassandra loses the battle with other NoSQL tech then cluster managements is probably it. Also, it's a bit unfair to compare RDBMSs with Cassandra. Clustering is inherently going to be more complicated for RDBMSs. Incidentally it's actually where I feel MongoDB deserves a bit of credit.

Reply on news.ycombinator.com