We Changed YugaByte DB Licensing to Apache 2.0(blog.yugabyte.com)
blog.yugabyte.com
We Changed YugaByte DB Licensing to Apache 2.0
https://blog.yugabyte.com/why-we-changed-yugabyte-db-licensing-to-100-open-source/
6 comments
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!
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!
We currently use CockroachDB in production and this is definitely going to make us take a serious look at YugaByte. We love Cockroach, but not really being able to do a distributed backup / restore operation without paying a million dollars is really annoying.
So are they not worried AWS will offer yugabyte as a service and edge them out of their own market? Maybe AWS wouldn't because of Aurora. And I guess the other's aren't large enough to matter.
Quoting the article,
“competition from AWS is simply the price to pay for developing OSS. Restrictive licensing including AGPL can slow down AWS but cannot stop it so the real impact of such licensing is lower user adoption. (...) this means that a commercial OSS company now has to compete with AWS on the merits of an exceptional DBaaS experience and not on the merits of the core OSS DB.”
“competition from AWS is simply the price to pay for developing OSS. Restrictive licensing including AGPL can slow down AWS but cannot stop it so the real impact of such licensing is lower user adoption. (...) this means that a commercial OSS company now has to compete with AWS on the merits of an exceptional DBaaS experience and not on the merits of the core OSS DB.”
One way for YB to fight off the competition from AWS would be to include a clause that any forks of the DB should always be in sync with the upstream(master developed by YB), so hypothetically speaking this would mean companies that are using the AWS YB could always have the freedom to switch to using the OSS YB and only risk loosing the features that AWS has contributed to its fork and might actually force the OSS to keep up.
So goodluck YB.
So goodluck YB.
(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 question - what is a database? The code or the query language? Anyway I digress).
We felt if we want to build something as foundational as PostgreSQL for the cloud, then we need to be as open.
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 question - what is a database? The code or the query language? Anyway I digress).
We felt if we want to build something as foundational as PostgreSQL for the cloud, then we need to be as open.
> We felt if we want to build something as foundational as PostgreSQL for the cloud, then we need to be as open.
Good intentions here, wish you guys the very best.
Good intentions here, wish you guys the very best.
I think the reason open source helps adoption is because:
A) I can conveniently install it and work with it via apt, yum, dnf, etc. for free at home.
B) I trust that the product will remain alive as long as its interest and users are, not when funding runs out.
Who wants to put time into vaporware? I don't want to pay for it until I know it's good and that it'll be around. I don't think being hostile to AWS takeover with change adoption.
A) I can conveniently install it and work with it via apt, yum, dnf, etc. for free at home.
B) I trust that the product will remain alive as long as its interest and users are, not when funding runs out.
Who wants to put time into vaporware? I don't want to pay for it until I know it's good and that it'll be around. I don't think being hostile to AWS takeover with change adoption.
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...
[1] https://thenewstack.io/the-slow-climb-of-postgres-and-the-va...
Great !
https://blog.yugabyte.com/rise-of-globally-distributed-sql-d...
I have found this article on their site to be useful. The article compares different SQL databases under Monolithic SQL Vs NewSQL Vs Globally Distributed SQL databases
https://blog.yugabyte.com/rise-of-globally-distributed-sql-d...
I have found this article on their site to be useful. The article compares different SQL databases under Monolithic SQL Vs NewSQL Vs Globally Distributed SQL databases
How does YugaByte compare to CockroachDB?
There's a feature matrix here [1] comparing YugaByte to CRDB, TiDB, Aurora, CosmosDB, Spanner, MongoDB, FoundationDB, Cassandra and Dynamo. No idea about performance characteristics though.
[1] https://docs.yugabyte.com/latest/comparisons/
edit: there is a relatively recent blogpost comparing the two here: https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-perform...
Key summary from the post:
In a nutshell, YugaByte DB delivers an average of 3.5x higher throughput and 3x lower latency compared to CockroachDB. Following are the detailed performance characteristics at scale (millions of rows) for internet-scale transactional workloads:
5x more insert throughput, 9x faster 4x more query throughput, 3x faster 4x more distributed transactions throughput In addition, YugaByte DB offers additional features such as read replicas (for timeline-consistent, low-latency reads from the local region) and automatic data expiry (by setting a TTL at table level or row level).
Obviously to be taken with a grain of salt as with all benchmarks doing head-to-head comparisons.
[1] https://docs.yugabyte.com/latest/comparisons/
edit: there is a relatively recent blogpost comparing the two here: https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-perform...
Key summary from the post:
In a nutshell, YugaByte DB delivers an average of 3.5x higher throughput and 3x lower latency compared to CockroachDB. Following are the detailed performance characteristics at scale (millions of rows) for internet-scale transactional workloads:
5x more insert throughput, 9x faster 4x more query throughput, 3x faster 4x more distributed transactions throughput In addition, YugaByte DB offers additional features such as read replicas (for timeline-consistent, low-latency reads from the local region) and automatic data expiry (by setting a TTL at table level or row level).
Obviously to be taken with a grain of salt as with all benchmarks doing head-to-head comparisons.
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.
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)
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!
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!
[deleted]
YugaByte product manager here -- have documented the answer to your question [1] As you can see, there are many similarities but there are also a few important differences such as depth of PostgreSQL compatibility (YB reuses PostgreSQL query layer while CRDB is a re-implementation) and latency/throughput observed for modern OLTP workloads.
[1] https://docs.yugabyte.com/latest/comparisons/cockroachdb/
[1] https://docs.yugabyte.com/latest/comparisons/cockroachdb/
That comparison misses some things like "AS OF SYSTEM TIME" queries, changefeeds, and other CRDB-specific pieces.
Hi @kodeblah,
True, but note that the comparison only focuses on SQL (as it related to PostgreSQL) features and not any DB-specific features.
The YugaByte DB specific pieces are not included as well - for example, support for YCQL (Cassandra-compatible) and YEDIS (Redis-compatible) APIs to the DB.
(disclosure: founder/cto at yugabyte)
True, but note that the comparison only focuses on SQL (as it related to PostgreSQL) features and not any DB-specific features.
The YugaByte DB specific pieces are not included as well - for example, support for YCQL (Cassandra-compatible) and YEDIS (Redis-compatible) APIs to the DB.
(disclosure: founder/cto at yugabyte)
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...
xvi(3)
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