Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 9.4 Released

postgresql.org

Post reply on HN
Print view View original

81–90 of 189 posts

Re: PostgreSQL 9.4 Released

#81

Post by tracker1 »

atonse wrote: post #11

Great news! I'd love to move over to this from MongoDB for a project that has high uptime requirements. But while I think the JSON will really replace it, does PG have a solution for High Availability (like replica sets) in the works? I'm newer to Postgres so am not sure. Replica Sets are the killer feature for me, more so than just storing JSON documents. I'd appreciate if someone can chime in. I've done some googli…

There are some open-source options, and several closed source options for this... parts are closer to baked in with 9.4, but being realistic, you need to defer to a commercial option.

EnterpriseDB pricing for this isn't too bad (about $7k/cpu-socket/year), which is a lot less than MS-SQL, DB2 or Oracle for most uses... but it's imho a feature that should be in the box.

Re: PostgreSQL 9.4 Released

#82

Post by Xorlev »

bkeroack wrote: post #70
personZ wrote: post #69

Earlier quoted context omitted.

I don't personally get the RDS value proposition, but how does it lead to vendor lock-in, much less severe vendor lock-in? I don't believe there is really any lock-in whatsoever -- backup your database and move it wherever you want, whether you're running the pgsql, Mysql, or SQL Server variants of RDS.

While of course you're correct, it's a bit like saying "you can just pack up your code and run it somewhere else". If the entire architecture and workflow are based around proprietary AWS tools (Elastic Beanstalk, Elastic load balancers, RDS, Cloud Formation, autoscaling, etc) even if your code is technically portable, you're still suffering from vendor lock-in. Arguably worse than the bad old days of the Microsoft m…

RDS is just a database though. All the standard tools work with it. Unless you start dipping into more exotic services, it's pretty hard to become locked in. EC2+ELB+RDS are fairly independent. Even autoscaling doesn't lock you in.

That said, CloudFormation, SQS, Kinesis, DynamoDB, etc. are all very sticky services.

Re: PostgreSQL 9.4 Released

#83

Post by threeseed »

codeaken wrote: post #39

Did PostgreSQL just kill MongoDB?

Only someone with a poor understanding of the industry would think that. Mongo is killing it in the enterprise and their partnerships with Teradata et al is only going to cement their position for likely decades to come.

Plus MongoDB's pluggable engine approach will definitely breath some new life into it.

Re: PostgreSQL 9.4 Released

#84

Post by personZ »

bkeroack wrote: post #70
personZ wrote: post #69

Earlier quoted context omitted.

I don't personally get the RDS value proposition, but how does it lead to vendor lock-in, much less severe vendor lock-in? I don't believe there is really any lock-in whatsoever -- backup your database and move it wherever you want, whether you're running the pgsql, Mysql, or SQL Server variants of RDS.

While of course you're correct, it's a bit like saying "you can just pack up your code and run it somewhere else". If the entire architecture and workflow are based around proprietary AWS tools (Elastic Beanstalk, Elastic load balancers, RDS, Cloud Formation, autoscaling, etc) even if your code is technically portable, you're still suffering from vendor lock-in. Arguably worse than the bad old days of the Microsoft m…

That's a bit of an extrapolation though, isn't it? Many people simply run VMs that connects to some arbitrary pgsql instance, which might happen to be on RDS if they want to simplify the management of that.

Those VMs can absolutely run almost anywhere, and they can connect to just about any instance of pgsql. I heavily use many services on AWS, but can quite literally move the entirety of it to my own servers, Google, Azure, or elsewhere in very short notice. People can choose to use some of the more unique services, but that is not related to RDS.

Re: PostgreSQL 9.4 Released

#85

Post by mgkimsal »

Is there an equivalent to the MySQL handlersocket stuff in postgresql?

http://www.percona.com/doc/percona-server/5.5/performance/ha...

http://www.slideshare.net/akirahiguchi/handlersocket-2010062...

It might go against the "no transaction" crowd, but seems useful for performance-critical needs. I'm scheduling a bit of testing time with it next week to see if it's something I'd roll out in production (Maria 10 system)

Re: PostgreSQL 9.4 Released

#86

Post by threeseed »

agentultra wrote: post #30
digitalzombie wrote: post #22

Earlier quoted context omitted.

How do you cluster in postgresql? Serious question, my prefer noSQL is cassandra and clustering is pretty easy. I ask this question every year and postgresql have not deliver this. If there is any, there are hardly any documentation on it.

> In 9.4, Logical Decoding supplies a new API for reading, filtering and manipulating the PostgreSQL replication stream. This interface is the foundation for new replication tools, such as Bi-Directional Replication, which supports the creation of multi-master PostgreSQL clusters. Other improvements in the replication system, such as replication slots and time-delayed replicas, improve management and utility of repli…

That's an API not a solution.

I do think (for once) PostgreSQL is addressing it's core weakness and by version 10 will likely have horizontal scalability locked down. The new API is a really positive step.

Re: PostgreSQL 9.4 Released

#87

Post by IndianAstronaut »

pilif wrote: post #5

Like every year before, the Postgres team has blessed us with an early christmas present. And like every release post before, I'd like to use this opportunity to say thanks to the team for the awesome job they are doing year after year. It's not just the database itself (and that's awesome on its own right), but it's also all the peripheral stuff: The documentation is seriously amazing and very complete, the tools th…

>even new contributors are not really required to have a thick skin nor flame retardant suits

I will have to look into this community more. I've been burned by some oss communities before.

Re: PostgreSQL 9.4 Released

#88

Post by gthank »

klaruz wrote: post #59
agentultra wrote: post #30

Earlier quoted context omitted.

> In 9.4, Logical Decoding supplies a new API for reading, filtering and manipulating the PostgreSQL replication stream. This interface is the foundation for new replication tools, such as Bi-Directional Replication, which supports the creation of multi-master PostgreSQL clusters. Other improvements in the replication system, such as replication slots and time-delayed replicas, improve management and utility of repli…

I think the problem is clustering is still very much a duct-tape situation in postgresql with no real clear consensus on how to build out a cluster. Postgres-XL looks great for scale out, but you need 4 independent types of servers. Even with all those moving parts, it doesn't provide availability. If you want fail-over, you need pacemaker for the data nodes with traditional sync replication, and something like VRRP…

If you honestly believe that all you have to do is stand up a bunch of instances of Mongo/Cassandra/whatever and you instantly get acceptable HA, then you need to read the [Jepsen series](https://aphyr.com/tags/jepsen)

Re: PostgreSQL 9.4 Released

#89

Post by petercooper »

bsg75 wrote: post #63
percept wrote: post #49

Earlier quoted context omitted.

_Beginning Postgres_, Cooper Press (2015)

Any ISBN or link for that? Google mostly returns old unrelated titles.

percept is winding me up ;-) Cooper Press is my company and I wrote a book called Beginning Ruby many moons ago. I wrote the first edition while learning the details of Ruby myself and I'd consider writing a Postgres book under similar circumstances if only I had the time! ;-)

Re: PostgreSQL 9.4 Released

#90

Post by gfodor »

bkeroack wrote: post #66
gfodor wrote: post #54

Earlier quoted context omitted.

The answer is simple, as with any AWS service, a whole slew of concerns (but not all of them) become Not My Problem. I have enough problems.

...in exchange for a number of different problems including (in no particular order): severe vendor lock-in, mediocre to acceptable performance, and relatively high cost per unit of performance.

Yup, and for startups this tradeoff is usually a no-brainer.
Post reply on HN