[Postgres-xl-general] Question on High Availability

Andrew Depue andrew.depue at kellpro.com
Thu Aug 28 08:39:25 PDT 2014


Hey, guys. We have a product that makes heavy use of Postgres. We have
known from the beginning that scaling out the DB back end would be the most
challenging aspect of our app, and are in the process of evaluating
different solutions to this. Postgres XL has shown up on our radar.
My basic question is, how do actual users of XL tend to solve the High
Availability side of the equation? Is this something that XL has built in?

We have two primary interests that are so common they almost go without
mentioning. That is, scaling performance, which Postgres XL seems to be
built for, and High Availability. After a quick skim of the XL
documentation I get the impression that HA isn't a primary concern of XL?
Please correct me if I am wrong.
So how do users of XL typically approach HA?

The rest of this e-mail is just for the sake of discussion. Feel free to
skip it.
Let me day dream a bit... XL would be a no brainer for us if we could just
add nodes and get both additional performance and additional redundant
storage - that is, I don't have to worry about setting up master and slaves
or anything of that nature. If a node goes down the system has redundant
copies of everything on other nodes. Like a RAID array, performance will
suffer a bit but the system keeps on trucking. We can later replace the
node, add more nodes, or whatever.
Basically, I want to have my cake and eat it too. We actually have this
very thing with our key store database. We are using an open source key
store that makes it brain dead easy to scale out. We add nodes, they join
the cluster, and everything starts redistributing - plus, it has HA and
redundancy built in. It also allows us to set up different data centers and
handles streaming changes between them. It just looks like one big
distributed key value store. We don't have to worry about setting up
master/slave relationships, WAL log shipping, or anything of the sort.
Now I know this is much more difficult to accomplish in a relational DB and
that one must make a few more compromises... but none of it is impossible
to solve.
To prove that point, we have found a commercial product based on PostgreSQL
that claims to do everything we need (we have yet to verify this or test it
ourselves). I won't name this product, but I'd wager that some devs on XL
are intimately aware of it.
So far our entire stack has remained open source and we would like to keep
it that way, though we aren't completely closed off to the idea of a
commercial solution.
Is XL headed in this direction at all? Does this even fit into its
philosophy? And if so, what would it take to get it here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.postgres-xl.org/pipermail/postgres-xl-general-postgres-xl.org/attachments/20140828/08036eb5/attachment.htm>


More information about the postgres-xl-general mailing list