Live data from Hacker News

Citus Unforks from PostgreSQL, Goes Open Source

citusdata.com

101–110 of 156 posts

Re: Citus Unforks from PostgreSQL, Goes Open Source

#101

AGPL license if anyone's curious: https://github.com/citusdata/citus/blob/master/LICENSE

Which means there is no chance this would ever become part of PostgreSQL proper.

That's correct, and with such a significant license change I think the term 'unfork' is being used inappropriately in the title.

Edit: the PostGIS extension is GPL, and that license choice has been very successful. Hopefully the AGPL works out at least as well for Citus, I'm just not familiar enough to know what the implications will be in this context.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#102
post #22

This is awesome. I have experience with running a CitusDB cluster and it pretty much solved a lot of the scaling problems I was having at the time. For it to go open source now, is of huge benefit to the future projects I have. > With the release of newly open sourced Citus v5.0, pg_shard's codebase has been merged into Citus... This is fantastic, sounds like the setup process is much simpler. I wonder if they have i…

(Ozgun from Citus Data) We're working on making Citus masterless. In all openness, we evaluated two different approaches to this in the past six months, and wrapped up the design for one. This design works well on the cloud, and we already demonstrated a working version: https://youtu.be/_nun2S6EdWo?t=411 For on-premise deployments, the primary challenge is set-up complexity. We're now prototyping one of those design…

Would it be possible (eventually) to use Citus for sharding within the datacenter, and BDR for master/master replication between datacenters?

Or is Citus taking over the master/master replication? (or is it doing something different?)

Re: Citus Unforks from PostgreSQL, Goes Open Source

#104

Being burned before,I will never use an OS infrastructure project that has enterprise features you need to pay for. They always try to move you to paid and make the OSS version unpleasant to use over time as soon as the bean counters take over to milk you "For customers with large production deployments, we also offer an enterprise edition that comes with additional functionality"

I definitely view "open core" products with greater skepticism than truly open source ones, but I think it comes down to the community surrounding (and engendered by) the sponsoring company/foundation. These Citus guys seem to be really enthusiastic about contributing their work to the community. That attitude mitigates any concerns I have, because to me it seems that they are really a part of the larger PostgreSQL community---not just trying to take advantage of it like certain companies whose names we won't mention.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#106
post #88
post #46

Earlier quoted context omitted.

...and Redshift. I love what Amazon provide, but it gets expensive.

(Part 3/3 - please see two comments below as the starting point) Aside from the different use-cases they address, there is one other, important difference between Citus and Redshift (and any other distributed database in the world, for that matter). Citus does not fork the underlying database, PostgreSQL. Instead, Citus extends PostgreSQL to transform it into a parallel processing, distributed database. We use Postgr…

I think that it would be better for you to position CitusDB by comparing it to other products in terms of use cases.

If the data is big and I need to run analytic queries then I think I have to use a columnar storage format because row-oriented formats cause too much overhead for aggregation queries that usually need to process single column efficiently. If I use CitusDB as an analytical database, then it's comparable with Redshift, Hive etc. As you said, they're suitable for offline data but Can I use cstore_fdw in CitusDB and able to take advantage of real-time nature of Postgresql? Maybe I can push hot data to a table that use row-oriented format and move the data periodically to another table that uses cstore_fdw and execute queries that fetches data from both cold storage and hot storage tables? If CitusDB makes it easy for me, then I think this is huge.

I guess another use case is using CitusDB as distributed data store and executing filter queries such as "SELECT * FROM table WHERE partition_key = x and predicate1 = y ...". Instead of using multiple Postgresql instances and routing the queries in application level, I can just use CitusDB that takes care of replication && query routing && sharding etc. I think it can also be comparable to databases such as Cassandra, Mongo (using jsonb) since they also have similar use-cases.

Or should I think CitusDB as distributed Postgresql?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#107
post #97

Earlier quoted context omitted.

I also have qualms about distributing changes to non-copyleft license code under a copyleft license, but it seems strange to make this the "slap in the face" moment - wasn't distributing them under a proprietary license even worse?

No that IS what the BSDL allows for. I wasn't arguing that they shouldn't have made a commercial product on BSDL code. That also was within their rights using said BSDL code. It's just my opinion that to do that, then release your proprietary "bits" under the GPL or variation thereof with more restrictions than what you started with instead of the same BSDL you used to start your business is a dickheaded douche nozzl…

I understand you weren't saying they don't have the right to do so, I just find it weird that you consider distributing it under the AGPL to be douchy, while not considering the distribution under a proprietary licence to be (even more) douchy.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#108
Does CitusDb fit in olap analytical workloads to do aggregations on hundreds millions of records using varying order and size of dimensions (eg druid) in max of 3 seconds response time using as few boxes as possible - Or there are other techniques have to be used along with Citusdb? Can you shed a light on your experience with CloudFlare in terms of cluster size and queries perf?

Re: Citus Unforks from PostgreSQL, Goes Open Source

#109

Earlier quoted context omitted.

The BSDL does not make much economic sense to the company open sourcing their code; a new competitor would fork the code, make closed improvements, and merge any changes from the open source code. That means that the competitor is always gaining by a one-way flow of improvements. To use open source code, the more permissive the license the better. But to actually open your own code, BSDL is a very tough sell. That's…

>> The BSDL does not make much economic sense to the company open sourcing their code If this were true then Cloudera, Horton and a whole bunch of other companies would be out of business, yet in reality they are doing really well. All that AGPL is doing for Citus is: 1. Turning away people (customers) who are religious about licenses. 2. Eliminating any possibility of this code ever being integrated into PostgreSQL

Cloudera and Hortonworks have raised a ton of VC money, but it is not clear (yet) that they have viable, profitable business models.

Re: Citus Unforks from PostgreSQL, Goes Open Source

#110
post #22

This is awesome. I have experience with running a CitusDB cluster and it pretty much solved a lot of the scaling problems I was having at the time. For it to go open source now, is of huge benefit to the future projects I have. > With the release of newly open sourced Citus v5.0, pg_shard's codebase has been merged into Citus... This is fantastic, sounds like the setup process is much simpler. I wonder if they have i…

(Ozgun from Citus Data) We're working on making Citus masterless. In all openness, we evaluated two different approaches to this in the past six months, and wrapped up the design for one. This design works well on the cloud, and we already demonstrated a working version: https://youtu.be/_nun2S6EdWo?t=411 For on-premise deployments, the primary challenge is set-up complexity. We're now prototyping one of those design…

What does "works well on the cloud" mean specifically? Is there some difference when run on your own hardware?
Post reply on HN