Live data from Hacker News

We Changed YugaByte DB Licensing to Apache 2.0

blog.yugabyte.com

21–30 of 30 posts

Re: We Changed YugaByte DB Licensing to Apache 2.0

#21

Earlier quoted context omitted.

(founder/cto of YugaByte) This is a very insightful suggestion, thanks for raising that! We had considered many of these variants until finally, we concluded that fully open is the best way. PostgreSQL (which is the database on fire right now) got to this spot by being fully open and permissive - and embracing all forms of competition. In fact, PostgreSQL got rewritten from Lisp to C (which begs an interesting questi…

Can you explain more about the rewrite from Lisp?

Postgres was first written in Lisp and had to be re-written in C because of slow performance [1]. YugaByte DB reuses the same C-based Postgres query layer but runs it on a Google Spanner-inspired distributed document store written in C++. The goal of this new “rewrite” is to add horizontal write scaling, native failover/repair and geo-distribution. As long as users love the language they interact with, the underlying software will continue to see such re-writes in order to meet the needs of the current times.

[1] https://thenewstack.io/the-slow-climb-of-postgres-and-the-va...

Re: We Changed YugaByte DB Licensing to Apache 2.0

#22
post #10

I think you mean it "raises the question". See: https://en.wikipedia.org/wiki/Begging_the_question Edit: To whomever downvoted this: care to justify your action?

We detached this subthread from https://news.ycombinator.com/item?id=20454328 and marked it off-topic.

Re: We Changed YugaByte DB Licensing to Apache 2.0

#23

Earlier quoted context omitted.

Going to vendor's website always have comparisons that claims, it can do everything that the competitor's can not. What I'd also like to know is limitations. Where it's not a good idea to use a product? This would help me make informed decision and build relationship with vendor based on trust. Best of luck with new licensing.

Thanks for your wishes @nishantvyas! This might help answer some of your questions: https://docs.yugabyte.com/latest/introduction/#what-are-the-... Please look at the trade-offs in the above section (vs SQL, vs transactional NoSQL, vs eventually consistent NoSQL). (founder/cto at YugaByte)

Joins and transactions across nodes, very cool. Inner joins/right joins too? Do these have similar time complexity, latency/bandwidth aside, as a comparably indexed traditional RDBMS?

Re: We Changed YugaByte DB Licensing to Apache 2.0

#24
post #23

Earlier quoted context omitted.

Thanks for your wishes @nishantvyas! This might help answer some of your questions: https://docs.yugabyte.com/latest/introduction/#what-are-the-... Please look at the trade-offs in the above section (vs SQL, vs transactional NoSQL, vs eventually consistent NoSQL). (founder/cto at YugaByte)

Joins and transactions across nodes, very cool. Inner joins/right joins too? Do these have similar time complexity, latency/bandwidth aside, as a comparably indexed traditional RDBMS?

Yes, we support all types of joins (inner, right included) and indexes. In fact, we recently also enabled stored procedures with plpgsql :)

Tuning to perform these efficiently in a distributed manner is a work in progress (this is wrt the time complexity question). The hints used by a traditional RDBMS would not be effective in the distributed case - optimizing this requires changing the optimizer and doing more "push-downs" to optimize the queries. Currently, depending on the query, these may or may not be fully optimized - but we hope to have good coverage soon!

Re: We Changed YugaByte DB Licensing to Apache 2.0

#25
post #2

How does YugaByte compare to CockroachDB?

GO-JEK did some performance benchmarking: https://medium.com/yugabyte/go-jeks-performance-benchmarking...

Something related to the benchmark: https://pingcap.com/blog/why-benchmarking-distributed-databa...

Re: We Changed YugaByte DB Licensing to Apache 2.0

#27
>However, the reality is that CockroachDB is not yet at the levels of adoption where AWS would be interested. So why did Cockroach Labs make the change?

Because it's too late once they get to that stage. The licence needs to be changed ahead of time. Because companies generally try to plan ahead more than a few months into the future.

I was following along with you until this point, but now I feel like you're trying to hard to paint these companies in a negative light and not give any benefit of the doubt.

I use CockroachDB and I have looked into your database recently. If I recall, your database dashboard was in the enterprise version only. I may look at it again now. I'll try to give you the benefit of the doubt (that you're not intentionally misrepresenting your competitors) even though you don't seem to be so charitable with your competitors.

Edit: Looks like dashboard is still proprietary. Also FYI, this page is unusable on my Pixel 2XL:

https://www.yugabyte.com/platform/#ee-1

Re: We Changed YugaByte DB Licensing to Apache 2.0

#28
post #27

>However, the reality is that CockroachDB is not yet at the levels of adoption where AWS would be interested. So why did Cockroach Labs make the change? Because it's too late once they get to that stage. The licence needs to be changed ahead of time. Because companies generally try to plan ahead more than a few months into the future. I was following along with you until this point, but now I feel like you're trying…

Hi @jazoom,

Thanks for your comment... had a couple of clarifications. Our take on the open-source licensing of CockroachDB/MongoDB has no implication on the features of these products. So in essence, you raised two separate points (one about the licensing, the other about the dashboard/features), happy to address both.

> Question about the dashboard

The portion of the dashboard that is not related to the orchestration is going to be open-source. This is a work in progress (it needs engineering work to separate these, and we're almost there). In fact, would love to have you beta test this if you're interested - please join our community slack and holler at me.

Note that we already had the core-DB open source - now we are making previously enterprise-only features open (like encryption at rest/on wire, distributed backups and read replicas). For comparison, CockroachDB (and MongoDB) had enterprise features - which were closed (and remain so). They made changes to the core-DB as well to prevent competition, effectively making it non-open-source (if you go by the definition of open-source).

Note that we're keeping "managed service" portion called YugaByte Platform under a closed license - this is the part that "manages" the cloud experience like creating nodes automatically, configuring security groups, etc. Not sure if these other companies have an equivalent product to this.

>> However, the reality is that CockroachDB is not yet at the levels of adoption where AWS would be interested. So why did Cockroach Labs make the change?

> Because it's too late once they get to that stage. The licence needs to be changed ahead of time. Because companies generally try to plan ahead more than a few months into the future.

> I was following along with you until this point, but now I feel like you're trying to hard to paint these companies in a negative light and not give any benefit of the doubt.

We named changes done by 4 companies (Elastic, Confluent, MongoDB, CockroachDB). Two of these are positive changes (Elastic and Confluent made only enterprise features closed, while the core is still open). MongoDB and CockroachDB closed their core as well with restrictive licenses. So we're simply calling that out.

MongoDB is being offered as a service by Azure CosmosDB and AWS. The licensing change done by MongoDB did not deter Amazon. Similarly, the enterprise features in Elastic were rebuilt by AWS and open-sourced into a fork. So the lesson here is - if a cloud provider wants to, they will build it anyway. Additionally, in the case of CockroachDB and YugaByte DB - AWS has Aurora, which is over a billion dollars in yearly revenue offering the same API as Postgres, so no net new functionality here. The few extra features offered by both these products can easily be replicated by AWS given the above. AWS is in fact more likely to build on Aurora rather than taking any of these services. So in the light of this, the above point of view seems fair.

PS: Will share internally about the link not working, thanks for pointing out!

Re: We Changed YugaByte DB Licensing to Apache 2.0

#29
post #10

I think you mean it "raises the question". See: https://en.wikipedia.org/wiki/Begging_the_question Edit: To whomever downvoted this: care to justify your action?

Pedantry about proscribed but commonly-used English that will not be misunderstood detracts from the conversation.

Pedantry may be your interpretation, but my comment was intended to provide some potentially interesting knowledge to the OP, who apparently appreciated it.

HN is a great medium for spreading fun facts, including more precise speech, and there are countless examples of this.

Since at least one person learned something from my comment before the thread was detached, and responded appreciatively, the evidence doesn't support this opinion or the actions taken.

Post reply on HN