3 ms·

The problem with PostgreSQL clustering, and really all SQL clustering is that the DB engine is just not designed with that in mind. So what you end up having to

The problem with PostgreSQL clustering, and really all SQL clustering is that the DB engine is just not designed with that in mind. So what you end up having to do is add an additional layer to support the clustering (or sharding). The advantage that something like MongoDB, or CouchDB, or Elasticsearch (etc) is that they're designed with sharding in mind. This makes the sysadmin's life a lot easier! Scaling Mongo up might be a pain with their config servers, routing servers, etc but at least there's a well-documented and well-supported system for scaling out horizontally. MySQL/PostgreSQL are fantastic database systems and exceptional at solving the problems they were designed for. But its wrong to think of it as this blanket solution for every problem, or to suggest it on HN every single time someone asks a question about MongoDB.

MichaelGG 12y ago
>all SQL clustering Uh that's simply not true? VoltDB, for instance, easily and natively supports sharding. SQL Server's AlwaysOn system (despite being failover clustering) is incredibly simple to setup and is transparent to clients. The OP is asking about a problem with only 1M records. Unless they're huge records or something, no one should be discussing such a small number of records as a performance limit.
- gaius 12y ago
  Hell, for only a million records, I'd "scale" with SQLite...
gaius 12y ago
Sorry but that simply isn't true, and I suspect you've not really done any serious RDBMS at scale - Teradata, DB/2, Oracle et al have had clustering baked in since the 90s, if not before. If you are talking about MySQL then sure.
Ronaldo777 12y ago
Relational databases provide a very solid foundation upon which a wide variety of replication, partitioning and data distribution schemes can be constructed. Just look at the different approaches that PostgreSQL supports: http://www.postgresql.org/docs/9.4/static/different-replication-solutions.html http://www.postgresql.org/docs/9.4/static/different-replicat... Other relational DB systems, from Oracle, to SQL Server, and even MySQL, offer similar functionality. Practice shows that they're very capable of successfully handling many different scenarios, even if some of these scenarios hadn't been considered decades ago when these relational database systems were first implemented. But that's just what happens when the core building blocks they do provide are so solid and fundamentally sound. It's only anecdotal evidence, but of all of the DB professionals I've worked with over the years, the ones who complained the least were always the ones working with some sort of relational DB system. The ones who complained the most have been working with some NoSQL database system. I've heard nothing but praise for the PostgreSQL documentation, while we repeatedly see submissions like this one asking for help with NoSQL scalability problems that just don't happen when using PostgreSQL, or Oracle, or SQL Server, or DB2, or MySQL, or even SQLite!

MichaelGG 12y ago

>all SQL clustering Uh that's simply not true? VoltDB, for instance, easily and natively supports sharding. SQL Server's AlwaysOn system (despite being failover clustering) is incredibly simple to setup and is transparent to clients. The OP is asking about a problem with only 1M records. Unless they're huge records or something, no one should be discussing such a small number of records as a performance limit.

gaius 12y ago
Hell, for only a million records, I'd "scale" with SQLite...

gaius 12y ago

Sorry but that simply isn't true, and I suspect you've not really done any serious RDBMS at scale - Teradata, DB/2, Oracle et al have had clustering baked in since the 90s, if not before. If you are talking about MySQL then sure.

Ronaldo777 12y ago

Relational databases provide a very solid foundation upon which a wide variety of replication, partitioning and data distribution schemes can be constructed. Just look at the different approaches that PostgreSQL supports: http://www.postgresql.org/docs/9.4/static/different-replication-solutions.html http://www.postgresql.org/docs/9.4/static/different-replicat... Other relational DB systems, from Oracle, to SQL Server, and even MySQL, offer similar functionality. Practice shows that they're very capable of successfully handling many different scenarios, even if some of these scenarios hadn't been considered decades ago when these relational database systems were first implemented. But that's just what happens when the core building blocks they do provide are so solid and fundamentally sound. It's only anecdotal evidence, but of all of the DB professionals I've worked with over the years, the ones who complained the least were always the ones working with some sort of relational DB system. The ones who complained the most have been working with some NoSQL database system. I've heard nothing but praise for the PostgreSQL documentation, while we repeatedly see submissions like this one asking for help with NoSQL scalability problems that just don't happen when using PostgreSQL, or Oracle, or SQL Server, or DB2, or MySQL, or even SQLite!