
We Changed YugaByte DB Licensing to Apache 2.0 - DarkManZero
https://blog.yugabyte.com/why-we-changed-yugabyte-db-licensing-to-100-open-source/
======
jazoom
>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](https://www.yugabyte.com/platform/#ee-1)

~~~
rkarthik007
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!

------
_jezell_
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.

------
eloff
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.

~~~
bozoUser
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.

~~~
rkarthik007
(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.

~~~
sansnomme
Can you explain more about the rewrite from Lisp?

~~~
sidch
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...](https://thenewstack.io/the-slow-climb-of-postgres-and-the-value-of-
persistence/)

------
truth_seeker
Great !

[https://blog.yugabyte.com/rise-of-globally-distributed-
sql-d...](https://blog.yugabyte.com/rise-of-globally-distributed-sql-
databases-redefining-transactional-stores-for-cloud-native-era/)

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

------
noncoml
How does YugaByte compare to CockroachDB?

~~~
tepidandroid
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/](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...](https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-performance-
benchmarks-for-internet-scale-transactional-workloads/)

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.

~~~
nishantvyas
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.

~~~
rkarthik007
Thanks for your wishes @nishantvyas!

This might help answer some of your questions:
[https://docs.yugabyte.com/latest/introduction/#what-are-
the-...](https://docs.yugabyte.com/latest/introduction/#what-are-the-trade-
offs-involved-in-using-yugabyte-db)

Please look at the trade-offs in the above section (vs SQL, vs transactional
NoSQL, vs eventually consistent NoSQL).

(founder/cto at YugaByte)

~~~
ralusek
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?

~~~
rkarthik007
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!

