7 ms·
We Changed YugaByte DB Licensing to Apache 2.0
- noncoml 7y agoHow does YugaByte compare to CockroachDB?
- sidch 7y agoYugaByte 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/ https://docs.yugabyte.com/latest/comparisons/cockroachdb/
- kodablah 7y agoThat comparison misses some things like "AS OF SYSTEM TIME" queries, changefeeds, and other CRDB-specific pieces.
- rkarthik007 7y agoHi @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)
- tepidandroid 7y agoThere'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-performance-benchmarks-for-internet-scale-transactional-workloads/ 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.
- deleted 7y ago[deleted]
- nishantvyas 7y agoGoing 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 7y agoThanks for your wishes @nishantvyas! This might help answer some of your questions: https://docs.yugabyte.com/latest/introduction/#what-are-the-trade-offs-involved-in-using-yugabyte-db 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)
- ralusek 7y agoJoins 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 7y agoYes, 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!
- sickeythecat 7y agoGO-JEK did some performance benchmarking: https://medium.com/yugabyte/go-jeks-performance-benchmarking-of-cockroachdb-tidb-yugabyte-db-on-kubernetes-9fde0127b00 https://medium.com/yugabyte/go-jeks-performance-benchmarking...
- ngaut 7y agoSomething related to the benchmark: https://pingcap.com/blog/why-benchmarking-distributed-databases-is-so-hard/ https://pingcap.com/blog/why-benchmarking-distributed-databa...
- eloff 7y agoSo 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.
- JoachimSchipper 7y agoQuoting 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.”
- bozoUser 7y agoOne 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 7y ago(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.
- bozoUser 7y ago> 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.
- xvi 7y agoI think you mean it "raises the question". See: https://en.wikipedia.org/wiki/Begging_the_question https://en.wikipedia.org/wiki/Begging_the_question Edit: To whomever downvoted this: care to justify your action?
- rkarthik007 7y agoI won't be making that mistake again! (I am talking about "begs the question" vs "raises the question" - no idea about the downvote).
- TazeTSchnitzel 7y agoPedantry about proscribed but commonly-used English that will not be misunderstood detracts from the conversation.
- xvi 7y agoPedantry 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.
- dang 7y agoWe detached this subthread from https://news.ycombinator.com/item?id=20454328 https://news.ycombinator.com/item?id=20454328 and marked it off-topic.
- truth_seeker 7y agoGreat ! https://blog.yugabyte.com/rise-of-globally-distributed-sql-databases-redefining-transactional-stores-for-cloud-native-era/ 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
- jazoom 7y ago>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 7y agoHi @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_ 7y agoWe 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.