Really nice seeing this commit, that I pushed this morning to Github, on the frontpage of HN a few hours later :) It's awesome that other people are just as excited about open-sourcing as we are. But if you like this definitely keep an eye on our blog[1] and/or twitter[2] for the upcoming "official" announcements. They will have a lot more info on this and all the other cool changes things that are part of Citus 11.
I submitted the news, sorry if I spoiled the announcement! ;) But as soon as I received the news, and these are definitely good news, I wanted to share it with the HN crowd :)
BTW, is item #8 (or any other, for that matter) an alternative to having to use .pgpass? Because this is a notable itch towards automation of Citus, would be great to see this resolved in the open source version.
I don't see this an "announcement of an announcement", as there's concrete and detailed content about the announcement itself. You can read the commit message and even the source code.
Moreover, I'm not affiliated with Citus and I don't know if they are planning later on an official announcement or not.
I stand by the idea of sharing these good news at the earliest for everyone interested to know, look at the code, and plan ahead of time if they need/want to.
I didn't say it was an 'announcement of an announcement' just that this
the idea of sharing these good news at the earliest
isn't really HN's remit, despite the 'news' in the name. The actual announcement is going to get posted as well and dupe-debated, etc. So there's no harm in waiting.
> I didn't say it was an 'announcement of an announcement' just that this
But it appears you didn't consider the following part of my comment, where I explained that a) I didn't have any way to know there would be a later announcement; and b) that there's enough interesting information with the current news that is worthwhile to many (definitely was for me), so there's no reason for holding it.
The important thing is the idea that it's important that something show up on HN asap is not accurate, it's not HN's thing, there's no harm in waiting as you can see in 9523772353.33 moderator comments.
I didn't have any way to know
I mean, they weren't going to keep it secret. Anyway, let's wrap up here.
> Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.
Is it possible to easily configure Postgres/Citus such that you can replicate your database across a managed offering such that if your database load is sufficiently high then you start using the managed offering, otherwise you use your managed offering?
Being able to combine the cheap compute of something like Hetzner with the high availability of a managed offering would be nice.
Does anyone have any experience building with Citus they can share?
I've been reading about it for years and it's always sounded very impressive to me - the magic sauce that you can sprinkle on regular PostgreSQL to have it scale horizontally - but I haven't yet had the opportunity to try it.
I've yet to make it out of the lab. The failover solutions seem to be A-B rather than A-B-DR. That is, you can have a primary and a replica (probably in the same DC/AZ), but you can't do a primary, a replica, and another replica in another datacenter that can function on its own (in a DR capacity).
Citus uses physical replication for worker and coordinator nodes, and things start getting complicated when you're trying to monitor the status of all the replicas. With vanilla PostgreSQL, you don't have this issue. I'm guessing that they solve this in Azure with block-device primitives at the storage level or something along those lines? It's probably not insurmountable to do it yourself, but we're not yet at the grip-n-rip enterprise offering.
Making HA easier while self-hosting is definitely something that's high on our list of future improvements. I wouldn't be surprised if there will be some announcements regarding this in the coming year. One of the main issues (imo) is configuring HA for PG isn't easy, even when using regular PG. And this becomes even more complicated in the case of Citus, because you're effectively running multiple PG servers, all of which you need to configure HA for.
For my understanding about the multi-region DR capability you would want: Do you want to be able to write to the DR region all the time? Or do you want to be able to switch over to the DR region in case the main DC is down?
Same here, wanna see some production usage testimonials. Plus has someone compared it to CockroachDB? I understand they are two different technologies with broader strokes of same idea of scaling Postgres horizontally but still would love to see some sort of comparison and differences.
I remember years ago, Citus offered people a free pair of socks as a bribe for signing up for their newsletter. I loved my database socks and gave them some free advertising during college.
I wonder if the decision to make all enterprise features open source was affected/influenced by the Neon release/announcement recently? The timing makes me wonder, or has this been planned for a very long time?
Either way, great news! I've been curious to try out Citus many times but the fact that many of the best parts has been closed has held me back a bit, I think it's great with more postgresql open source extention options.
This is fantastic, and should bring some relief to those who want to self-host Citus outside of Azure. I wonder if TimescaleDB's recent license changes had anything to do with this.
I'm not sure what "recent license changes" you are referring to?
The Timescale License was introduced in late 2018, although we never _relicensed_ any of our Apache 2 code, we only created a space for _new_ capabilities to be developed under these terms.
There were a few changes to the license in Sept 2020, but those only liberalized a few clauses (including from feedback we received from the Hacker News community, including the "right to repair" and "right to improve"). At the time, we also moved any remaining "enterprise" features from an Enterprise/Paid license into the TSL/Community/Free license.
This one surprised all of us on the Citus dev team, when we were reviewing what we were open sourcing. This "feature" was never intended to be Enterprise only and not having it in the open source repo was simply an honest mistake. If some open source user had asked for it I'm certain we would have also added it to the open source version. But so far no-one asked.
At least this mistake is resolved now, and no new ones like it should occur, since we will only commit to the open source repo now.
For my part, I should perhaps clarify (if it was not already obvious) that my comment was a generic comment intended towards all such companies and not specifically targeted at Citus.
I for one am immensely happy that mholt and team made the decision to re-open source Caddy, and I wish them all the best in the future. It's truly a wonderful piece of software.
As an early backer of Caddy I don't think I ever touched it again after what I felt as a bait and switch weeks(?) after my donation to an open source product.
Maybe it is time to reconsider now, because I really really really liked Caddy back then, which is probably why I donated enough to make me equally annoyed when I felt I had been had.
Caddy is amazing! My most favourite feature at the moment is on-demand TLS, which I'm using in my SaaS project (not launched yet) to allow customers to use a custom domain.
Enterprise crippleware is obnoxious. So are restrictive and radioactive licenses like AGPL. What bugs me are those who speak out of the sides of their mouth how it's not with different flavors of rationalized BS.
Bug fixing priority, tech support, and integration consulting are the proper places to monetize, not features for-profit express turnpike or telling me what I can't do with code.
AGPL doesn't require that $bigCorp give you the changes, only that they give their users the changes. You could get changes from existing users, but they might not be willing or able to help you. You could become a user, but that could be expensive or $bigCorp could just ban you from the service.
I really can't say whether that's correct or not. IANAL.
The licence in terms says you must give Corresponding Source to users "interacting with it remotely through a computer network". Does it suffice if I initiate a connection to a public $bigCorp server (and receive "access denied")? Or must I be able to successfully connect?
Maybe $bigCorp could put a proprietary authentication proxy in-between to avoid me "interacting with" the software. So, let me narrow my comment to address what you've said.
If $bigCorp wants to rent me access to improved versions of my software, they should give me the changes.
Not sure about your questions since IANAL but I guess it depends on the details of how $bigCorp's server setup works. If they have some other software that controls access to the AGPLed software, then maybe they don't have to give non-customers source code. If the login form comes from the AGPLed software, but non-customers don't have a login, then maybe the non-customers do interact with the software in a limited way, so source code obligations may come into play.
While I would like to voice a general protest against the AGPL FUD, it's also somewhat strange to do it in the same breath as "Much respect" for Citus here.
> Bug fixing priority, tech support, and integration consulting are the proper places to monetize
Yeah ... the problem is, you can't charge a corporate millions of dollars for that off the bat, but you sure can charge the millions of dollars for software licensing. And they are happy to pay it. In fact, they want to pay to it, it makes them feel more secure and they have a budget to use.
The easy way to do that is to have themes and branding. Call it something else. "Enterprise Edition". Then they can enjoy the nice, warm fuzzy feeling of different logos.
While it does seem like a perverse incentive, there will always be more customers than you are able to provide service to anyway, since no matter how good your documentation and how perfect your install process, issues will arise at the boundaries between your software and the customer's other systems, so integration services are valuable. In complex systems there will be more bugs than you can fix, so prioritization is valuable. Support is valuable because of the customers who have less experience with the software than you.
Nothing about AGPL prevents anyone monetizing bug fixing, tech support and integration consulting. You can also do whatever with the code. You just need to provide it if you host the project as a service.
Of course, PG maintainers will only want to lift what they can maintain and has a compatible release cadence. But it wouldn't be the first time that Citus' work has landed in PG core.
Citus itself is AGPL, iirc, and it uses the PostgreSQL extension API and isn't a fork. Besides being carried in the contribs extension tree and possibly being a part of project internal tests, I don't really see what having it developed there would necessarily bring. Are there any other benefits/drawbacks I've missed?
This is great news I will definitely try to support a model where citus get paid (presumably consultancy) in the future and it’ll be my go to upgrade from postgres. I could probably use their sharding features fairly soon on the startup I’m building!
