
What it means to be a Postgres extension - akane
https://www.citusdata.com/blog/2017/10/25/what-it-means-to-be-a-postgresql-extension/?hn
======
oliwarner
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 had to compile the
whole Postgres+Citus database, for every platform they support, in a timely
manner, test it and distribute packages. Think of all the CPU cycles and
bandwidth they're saving by only having to compile as an extension against
public headers.

Functioning as an extension means Postgres and its distributors (eg Ubuntu)
are the people responsible for keeping Postgres alive and secure. Citus only
have to support their thing.

Why aren't they talking about how much this move is saving them in day-to-day?
There's no shame in being efficient.

~~~
bane
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.

~~~
oliwarner
You're already dependent. Upstream can turn around tomorrow and provide
everything your fork/extension does for free. They can alter their entire
codebase to cause you weeks of work to keep up. It can be a hard slog being
downstream, no doubt about it. That's why downstreams tend to "get involved"
upstream. Sponsorship, sit on technical advisory boards, etc.

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.

------
simooooo
They were surprised that maintaining a postgres fork was a pain in the ass?

~~~
stubish
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.

~~~
jacques_chester
> _I think it was more that forks just get ignored_

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.

------
StreamBright
Citus is my favorite website when it comes to Postgres content. Their blog
posts are usually very informative and useful.

~~~
areskib
I couldn't agree more, I'm amazed by every single one of their post. They are
doing a great job at communicating and giving rich insights on Postgres.

------
mosselman
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?

~~~
manigandham
No. Postgresql is a single-node database. It supports replication and failover
to other nodes and foreign-data-wrapper extensions that let it query other
datasources, but it does not have any support for natively working as a
distributed database across several nodes.

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).

------
siscia
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?

~~~
brightball
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.

~~~
manigandham
You already have options:

[https://aiven.io](https://aiven.io)

[https://www.databaselabs.io/](https://www.databaselabs.io/)

