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.
Congratulations for the commit!
And no worries about spoiling the announcement a bit. Seeing this on the frontpage of HN made my day!
It's a natural impulse but somewhat counterintuitively
One way to think of it is as repetition-prevention since a big enough story is going to end up on the front page one way or the other.
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.
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.
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.
I didn't have any way to know
I mean, they weren't going to keep it secret. Anyway, let's wrap up here.
(sadly the accompanying HN submission got marked as a duplicate from this submission)
Btw HN, if you share the sentiment about more open source, please feel free to star us on GitHub :)
Thank you for your work Citus Team.
Being able to combine the cheap compute of something like Hetzner with the high availability of a managed offering would be nice.
We were using it for a few years and though we transitioned to pure PG - that database is still named “citus” in honor of what citus did for us.
Glad to see the open sourcing - especially the backups (which is why we switched). That’s really important.
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.
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.
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?
+ Implementation of the UK Coronavirus Dashboard running on Citus and Postgres, a post co-authored by the technical lead of the dashboard, Pouria Hadjibagheri: https://www.citusdata.com/blog/2021/12/11/uk-covid-19-dashbo...
+ Architecting petabyte scale analytics using Postgres and Citus, based on an interview with the user, Min Wei: https://www.citusdata.com/blog/2019/12/07/petabyte-scale-ana...
+ Video of a customer talk about scaling a SaaS application on Citus by Jonathan Denney at ConvertFlow: https://youtu.be/PzGNpaGeHE4
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.
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.
We haven't changed anything since, nor have we ever moved any Apache-2 code into the TSL.
Side-note, I had a bit of fun with the pronunciation & spelling challenges of working on Postgres and Citus here: https://twitter.com/clairegiordano/status/150378415161432064...
There is a special place in hell for companies that consider basic encryption to be an "enterprise" feature in 2022.
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.
Citus appears to be an extension to Postgres that allows easier distribution, replication, sharding, parrallelism etc.
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.
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.
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.
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.
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.
I know this is a widespread business model, but it's always seemed backwards to me.
Having my customers pay me more when I produce more bugs and lower usability? That sounds like a reward for doing a bad job.
Hope more open source adaptation, to a point that i could use it in production.