21–30 of 49 posts
I tried Yugabyte a few weeks back, the TServer kept crashing while my backend was creating some very simple tables. I'm stuck with CockroachDB for the time being.
> I'm stuck with CockroachDB for the time being. Would you care to share any negative experiences you've had with CockroachDB? What is motivating your desire to look elsewhere?
Yugabyte has great articles in general and seems almost to be good to be true what I have read. It is just missing a bit of independent third party reviews but it does look interesting. Anyone with hands on experience?
Yugabyte v. Cockroach analysis: https://www.cockroachlabs.com/blog/unpacking-competitive-ben... disclaimer: I work at cockroach
The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership with AWS showing how far you could push AWS Aurora using Vitess ( https://planetscale.com/news/planetscale-aws-benchmark )
Secondly is the claim that there are no distributed transactions or cross shard joins. There are in fact distributed transactions, and cross shard joins. You can in fact do full cross shard ACID transactions. We do recommend that you are aware of the sharding mechanism as we will not trigger a cross shard transaction unless we need to.
Finally they do say there is no Native Failover/Repair which is only technically accurate. We use a third party tool called orchistrator to do the fail overs, and we recommend you run that along side the cluster so yes its not "built in", but it will launch as part of our Helm Chart fully configured to automatically do native fail overs.
I am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership wi…
Earlier quoted context omitted.
From your link: > 2019-09-05: YugaByte’s blog post states YugaByte DB “passes Jepsen tests”. We feel obligated to state that YugaByte DB’s Jepsen test suite does not pass, though it may in the future. Race conditions in YugaByte DB’s schema system can cause correctness errors. For example, inserting rows into a freshly-created table with DEFAULT values may result in the values for those columns initialized to NULL in…
I don’t know the case at yugabyte but, in general, the outright lies by sales has nothing to do with the integrity of the developers.
Earlier quoted context omitted.
> I'm stuck with CockroachDB for the time being. Would you care to share any negative experiences you've had with CockroachDB? What is motivating your desire to look elsewhere?
A few weeks back after my attempt to switch to Yugabyte I decided to commit to CockroachDB in a dedicated cluster with TLS, my backend runs migrations including creating the database but only admins and root are able to create databases but because TLS was enabled my root user didn't work anymore. I was not able to create more admin users because that's part of the RBAC Enterprise offering. The database was there but…
To start with, any scenario that you find where a secure deployment without an Enterprise license makes you unable to operate your apps using the core features, would be a serious bug on our side and we'd give it high priority. There is no intent to do bait-and-switch here.
If I read between your lines I can see the following:
- you need an admin user to create databases;
- the only admin user is root;
- it appears that you cannot log in with root on a secure cluster (TLS enabled). Is that understanding correct?
I think I understand the following: your SQL client is attempting to connect using TLS but without presenting the root client cert to the server. The root client cert is a cert that you can generate using the cluster's CA key (using the `cockroach cert` command). Without a valid client cert, the connection is refused.
You may think this seems to work for other users than root. This is because for other users, when cert validation fails, the server allows the client to use a password instead. This choice to use a password is not available for the root user up to and including 19.2.
Here is your way forward:
- either you configure your SQL client that creates database to present the root client cert to the server. This will enable you to use the root account on a secure server and create databases (and other users, and then assign privileges to these users over the new database).
- or, you wait until crdb 20.1, where it will be possible to configure a password for the root user and let root clients use password authentication instead of presenting client TLS certs.
Does this help?
If it doesn't please create an issue on github and describe your situation in more details and cc me (@knz). Thank you
I am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership wi…
Vitess runs YouTube. Mic drop. Nothing else to say.
Yugabyte has great articles in general and seems almost to be good to be true what I have read. It is just missing a bit of independent third party reviews but it does look interesting. Anyone with hands on experience?
Yugabyte v. Cockroach analysis: https://www.cockroachlabs.com/blog/unpacking-competitive-ben... disclaimer: I work at cockroach
I am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership wi…
In particular, it is an order of magnitude better than the displayed CockroachDB benchmark[0], with 81 c5d.9xlarge nodes instead of Vitess’ 64 r4.16xlarge.
Can you still beat that with MySQL or MariaDB?
[0]: https://www.cockroachlabs.com/docs/v19.2/performance.html
I am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership wi…
Vitess is great. Although I am wondering whether the Planetscale achievement is partially attributable to the fantastic work put in the closed-source Aurora. In particular, it is an order of magnitude better than the displayed CockroachDB benchmark[0], with 81 c5d.9xlarge nodes instead of Vitess’ 64 r4.16xlarge. Can you still beat that with MySQL or MariaDB? [0]: https://www.cockroachlabs.com/docs/v19.2/performance.h…