7 ms·

Only thing I would caution here is that Postgres HA is notoriously difficult to set up and get right. Something like CouchDB is designed from the ground up for

Only thing I would caution here is that Postgres HA is notoriously difficult to set up and get right. Something like CouchDB is designed from the ground up for high availability and scalability. So if your design calls for only a document store, probably best to avoid Postgres.

empthought 11y ago
This is flat-out misleading. PostgreSQL is also designed "from the ground up for high availability and scalability," it's just optimized for a different -- and far more common and useful -- set of system assumptions and constraints. Unfortunately those assumptions and constraints don't make good blog or product marketing material copy. "We have a typical LOB app," "our data needs are nothing extraordinary," etc.
- coderzach 11y ago
  Postgres isn't designed from the ground up for high availability or scalability. Most of the in-built functionality for setting up HA wasn't introduced until 9.0, and the process of setting up HA postgres with automatic failover requires third-party tools. As for scalability, postgres can only scale vertically. If you need a solution that can scale writes to more than than one node, or a solution that has first party support for HA with automatic failover, you shouldn't be using postgres. As an aside, I find the dogmatic "just use postgres for everything" choir just as bad as the marketing BS associated with noSQL databases.
  - snuxoll 11y ago
    Unless you are using synchronous replication (locks up transactions if there is an issue with replication) there's no safe way to do automatic failover with an RDBMS without using shared storage (expensive, pain in the butt). Corosync and pacemaker make setting up automatic failover with shared storage relatively painless. I don't do it this way personally because shared storage is a giant pain.
  - empthought 11y ago
    "High availability" and "high availability with automatic failover" are not the same thing. (The tricky bit is actually the un-failing-over part.) I assure you that people were setting up high availability systems with PostgreSQL 7.x in 2004 or so. Very few organizations need to scale their database in any other direction than vertically. If it works for Stack Overflow, it's certainly likely to work for your application.
    - takeda 11y ago
      It's also lack of understanding the problem you're trying to solve. For example at my previous job we had a dedicated data store for performing lookups such as ip -> zip code and latitude/longitude -> zip code. The company decided to use Oracle Coherence and store all data in memory, because it'll be fast. To store all of that information they needed 16 m3.medium machines. Last year they had a great success optimizing it, because they managed to replace 16 x m3.medium machines to just 3 x c3.2xlarge machines running MongoDB (the data was ~12GB). I did a POC and put the data in PostgreSQL with proper columns and indices (I just needed to install ip4range and PostGIS), the whole data fit in 600MB! the queries took under at most 2ms on cold cache but generally were under miliseconds, because all the data fit in RAM.
      - threeseed 11y ago
        It seems more of a problem with the people than technologies. Why would you need 16 m3.medium (60GB RAM total) to store 600MB of data ? I've used Oracle Coherence and other grid technologies and something doesn't sound right here. It is just a couple of distributed Java HashMaps we are taking about here. Likewise if 600MB of data is expanding to 12GB in MongoDB then something is very, very wrong with the design of your schema.
        empthought 11y ago
        > It seems more of a problem with the people than technologies. Isn't that what "lack of understanding of the problem you're trying to solve" means? Though in this case, if the problem had "IP4 ranges" and "geographic data and computation functions" in its scope, then MongoDB is quite inadequate compared to PostgreSQL.
- brightball 11y ago
  My best attempt at PostgreSQL marketing material copy. :-) http://www.brightball.com/postgresql/why-should-you-learn-postgresql http://www.brightball.com/postgresql/why-should-you-learn-po...
  - merb 11y ago
    Good stuff expect Listen Notify. it's too dependent on the driver. I mean some drivers needs some kind of polling which is, aweful. Mostly you could go around this issue by opening another connection without going through your database pool and building a simple driver just for listen/notify. (jdbc I'm looking at you)
    - brightball 11y ago
      Most of the uses of it that I've seen have taken this approach with a listener on a thread using a different connection.
snuxoll 11y ago
PostgreSQL HA is not that difficult to setup, repmgr makes the task pretty easy. If you are talking about automatic failover then that's another story entirely, because it is simply not appropriate for relational databases unless you are using shared storage (expensive, painful) - but if you want to go that route corosync and pacemaker have your back.
__jal 11y ago
PG HA really isn't difficult to set up. You have to know about your environment and how you use the DB, but if that's limiting factor then I'm really not sure why you'd try to set up HA.
bsaul 11y ago
I've read many answers to your comment saying "but it's not that hard". So to all those people : please, write a blog or send a link to one that explains how to setup a HA cluster with automatic failover. I've spent some time trying to setup a simple pg cluster once ( not even HA, just duplicate writes) and it was nothing but straightforward.

empthought 11y ago

This is flat-out misleading. PostgreSQL is also designed "from the ground up for high availability and scalability," it's just optimized for a different -- and far more common and useful -- set of system assumptions and constraints. Unfortunately those assumptions and constraints don't make good blog or product marketing material copy. "We have a typical LOB app," "our data needs are nothing extraordinary," etc.

coderzach 11y ago
Postgres isn't designed from the ground up for high availability or scalability. Most of the in-built functionality for setting up HA wasn't introduced until 9.0, and the process of setting up HA postgres with automatic failover requires third-party tools. As for scalability, postgres can only scale vertically. If you need a solution that can scale writes to more than than one node, or a solution that has first party support for HA with automatic failover, you shouldn't be using postgres. As an aside, I find the dogmatic "just use postgres for everything" choir just as bad as the marketing BS associated with noSQL databases.
- snuxoll 11y ago
  Unless you are using synchronous replication (locks up transactions if there is an issue with replication) there's no safe way to do automatic failover with an RDBMS without using shared storage (expensive, pain in the butt). Corosync and pacemaker make setting up automatic failover with shared storage relatively painless. I don't do it this way personally because shared storage is a giant pain.
- empthought 11y ago
  "High availability" and "high availability with automatic failover" are not the same thing. (The tricky bit is actually the un-failing-over part.) I assure you that people were setting up high availability systems with PostgreSQL 7.x in 2004 or so. Very few organizations need to scale their database in any other direction than vertically. If it works for Stack Overflow, it's certainly likely to work for your application.
  - takeda 11y ago
    It's also lack of understanding the problem you're trying to solve. For example at my previous job we had a dedicated data store for performing lookups such as ip -> zip code and latitude/longitude -> zip code. The company decided to use Oracle Coherence and store all data in memory, because it'll be fast. To store all of that information they needed 16 m3.medium machines. Last year they had a great success optimizing it, because they managed to replace 16 x m3.medium machines to just 3 x c3.2xlarge machines running MongoDB (the data was ~12GB). I did a POC and put the data in PostgreSQL with proper columns and indices (I just needed to install ip4range and PostGIS), the whole data fit in 600MB! the queries took under at most 2ms on cold cache but generally were under miliseconds, because all the data fit in RAM.
    - threeseed 11y ago
      It seems more of a problem with the people than technologies. Why would you need 16 m3.medium (60GB RAM total) to store 600MB of data ? I've used Oracle Coherence and other grid technologies and something doesn't sound right here. It is just a couple of distributed Java HashMaps we are taking about here. Likewise if 600MB of data is expanding to 12GB in MongoDB then something is very, very wrong with the design of your schema.
      - empthought 11y ago
        > It seems more of a problem with the people than technologies. Isn't that what "lack of understanding of the problem you're trying to solve" means? Though in this case, if the problem had "IP4 ranges" and "geographic data and computation functions" in its scope, then MongoDB is quite inadequate compared to PostgreSQL.
brightball 11y ago
My best attempt at PostgreSQL marketing material copy. :-) http://www.brightball.com/postgresql/why-should-you-learn-postgresql http://www.brightball.com/postgresql/why-should-you-learn-po...
- merb 11y ago
  Good stuff expect Listen Notify. it's too dependent on the driver. I mean some drivers needs some kind of polling which is, aweful. Mostly you could go around this issue by opening another connection without going through your database pool and building a simple driver just for listen/notify. (jdbc I'm looking at you)
  - brightball 11y ago
    Most of the uses of it that I've seen have taken this approach with a listener on a thread using a different connection.

snuxoll 11y ago

PostgreSQL HA is not that difficult to setup, repmgr makes the task pretty easy. If you are talking about automatic failover then that's another story entirely, because it is simply not appropriate for relational databases unless you are using shared storage (expensive, painful) - but if you want to go that route corosync and pacemaker have your back.

__jal 11y ago

PG HA really isn't difficult to set up. You have to know about your environment and how you use the DB, but if that's limiting factor then I'm really not sure why you'd try to set up HA.

bsaul 11y ago

I've read many answers to your comment saying "but it's not that hard". So to all those people : please, write a blog or send a link to one that explains how to setup a HA cluster with automatic failover. I've spent some time trying to setup a simple pg cluster once ( not even HA, just duplicate writes) and it was nothing but straightforward.