21–30 of 35 posts
Citus is my favorite website when it comes to Postgres content. Their blog posts are usually very informative and useful.
Can anyone shed some light on how the supposed new cluster features of Postgres 10 compare to something like Citus? In other words. Does Postgres 10 offer the same features in terms of clustering as Citus does?
https://wiki.postgresql.org/wiki/Replication,_Clustering,_an...
And Citus is the first link in that list.
They were surprised that maintaining a postgres fork was a pain in the ass?
I think it was more that forks just get ignored. Customers want to run PostgreSQL, not something almost but not quite like PostgreSQL maintained by a company that may or may not employ PostgreSQL core contributors. And we certainly don't want to talk to your sales team about why it is a better fit for our use case. The stuff Citus has been landing in PostgreSQL is fantastic.
They call out a number of forks that do quite nicely. I work for Pivotal, which sponsors Greenplum. Companies pay handsomely for the capabilities it brings to the table.
But they are right that rebasing is a nightmare. My understanding (possibly wrong) is that the broad selection of APIs that make an extension-only approach did not appear in PostgreSQL until more recent versions -- anyone who forked earlier (such as Greenplum) have to first catch up and then migrate.
I do know that the Greenplum team have decided to catch up until they are working against mainline. It is, as you might imagine, a slow process: rebasing millions of lines of code a release at a time is not the easiest task on earth. But maintaining a fork will, in the long run, be harder.
Since we are talking about postgres, please let me go a little OT Is there any interests in a RDS as a Service? So basically setting up and running a completely fault aware postgres cluster in any infrastructure, either public or private?
Since it uses BOSH, you can deploy to a wide range of targets. OpenStack, vSphere, AWS, Azure, GCP and I forget what else.
Disclosure: I work for Pivotal.
This seems like a VERY shallow analysis of the benefits. Forking an industrial-grade tool means the entire lifespan of the entire product becomes your responsibility to your client. Tracking the major upgrade changes might be a pain in the arse but they're nothing compared to tracking every security and data-loss fix that bubbles around the Postgres community. It's not just developer time that's the cost here. They h…
This seems like a VERY shallow analysis of the benefits. Forking an industrial-grade tool means the entire lifespan of the entire product becomes your responsibility to your client. Tracking the major upgrade changes might be a pain in the arse but they're nothing compared to tracking every security and data-loss fix that bubbles around the Postgres community. It's not just developer time that's the cost here. They h…
Being an extension also makes you entirely dependent on somebody else's platform, and makes it possible that your work will simply be subsumed by the platform if they think it's important enough. It's a very weak business position to be in and you have to have incredible future looking planning and brand buy-in to make sure you succeed like this.
This seems like a VERY shallow analysis of the benefits. Forking an industrial-grade tool means the entire lifespan of the entire product becomes your responsibility to your client. Tracking the major upgrade changes might be a pain in the arse but they're nothing compared to tracking every security and data-loss fix that bubbles around the Postgres community. It's not just developer time that's the cost here. They h…
Being an extension also makes you entirely dependent on somebody else's platform, and makes it possible that your work will simply be subsumed by the platform if they think it's important enough. It's a very weak business position to be in and you have to have incredible future looking planning and brand buy-in to make sure you succeed like this.
But what you're saying —which wasn't immediately obvious, and correct me if I'm wrong— is your users are using your database product, not Postgres, so you can hold them back as long as you like when they're using a forked product. They won't be carried away by an automatic update and it's much harder for them to jump ship.
And while there is some truth to that, it comes with a karmic cost. People picked you because you were based on their favourite, industry tested database. If you slip behind in features, or (more importantly) can't backport security fixes instantly, you're dead.
Can anyone shed some light on how the supposed new cluster features of Postgres 10 compare to something like Citus? In other words. Does Postgres 10 offer the same features in terms of clustering as Citus does?
Citus is an extension that takes several database nodes and makes them appear as a single logical database server (at the table level, by automatically sharding them based on a column).
Since we are talking about postgres, please let me go a little OT Is there any interests in a RDS as a Service? So basically setting up and running a completely fault aware postgres cluster in any infrastructure, either public or private?
Yes, but the trick with it is pricing it so that I have a reason to use it instead of just using RDS. If I could get something like that on Digital Ocean I’d be all over it.
Since we are talking about postgres, please let me go a little OT Is there any interests in a RDS as a Service? So basically setting up and running a completely fault aware postgres cluster in any infrastructure, either public or private?
Basically as if I hired a contractor to install, monitor and upgrade, but automated. Existing services charge too much since they resell VMs and storage, while also being less flexible with access and performance.
There's also the rise of Kubernetes (with operators, helm charts and persistent storage) that takes away much of the complexity. By version 2.0, it should be able to easily make any legacy single-node system into a fault-tolerant service.