[rkrzr]

This is fantastic news! Postgres does not have a terribly strong High Availability story so far and of course it also does not scale out vertically. I have looked at CitusDB in the past, but was always put off by its closed-source nature. Opening it up seems like a great move for them and for all Postgres users. I can imagine that a very active open-source community will develop around it.

[hblanks]

We've been running CitusDB for a couple years now at CloudFlare for serving aggregated analytics to customers (cf. https://blog.cloudflare.com/scaling-out-postgresql-for-cloud...).

It's a good product, and it was even fairly easy to do a major version upgrade / cluster relocation. At least as easy as such a thing can be. :-)

[rkrzr]

Are there any limitations you have run into? E.g. can you still use all index types that Postgres offers or are there any special distributed index types that CitusDB adds perhaps?

[hblanks]

Correct. CTEs are pretty much a no-go, and you also can't do things like join between distributed and non-distributed tables.

Your queries tend to break down into ones where you're hitting a small number of shards (such as when we serve data for the analytics page), or else ones where you tend to aggregate up into temporary, non-distributed tables for further analysis (such as you'd do for infrequent business reporting).

All told, it's been one of the easier tools for us to operationalize, largely thanks to the fact that it's "just PostgreSQL." The one thing I wish we had was better documentation of what kind of consistency guarantees to expect, although for an append-only store like our current use case, that's less of a concern. And to be fair, Ozgun and the other guys at Citus have always been really happy to answer any questions we have.

With this code now going open source, it should be pretty easy to look into these sorts of internals.

[makr17]

My recollection from the last time I played with it, some bits from core postgres are unsupported; things like sequences and recursive CTEs. Maybe all CTEs?

[tlarkworthy]

nit: Postgres doesn't scale horizontally, it only scales vertically.

[andrewflnr]

I guess if you're putting more servers in a rack, it does tend to be a vertically-oriented process. :)

[manigandham]

It doesnt scale vertically either. Postgres is single-threaded meaning it can't make use of multiple CPU cores on the same machine. There have been some slow improvements to this and 9.6 seems to hint at some parallel aggregation changes but overall Postgres is strong in features but weak in scaling (in any direction).

[anarazel]

"hint at"?

[manigandham]

https://news.ycombinator.com/item?id=11331602

It looks good, will have to wait and see what actually makes it into 9.6 and how well it supports all the possible queries. This is something that many commercial databases have solved so Postgres is pretty behind in vertical scaling.

[anarazel]

To me it's a bit weird calling committed patches "hints".

[tlarkworthy]

British English vs. American English? I dunno if the poster is British but I am. I read that they haven't done enough to call pg vertically scalable but recent work suggestions (hints) that they are working toward it. The expression is more metaphorical than literal, an Atlantic divide my American colleagues explicitly warn me about when I am writing my perf reviews.