Viewing profile — sidch

Yugabyte PM here. Yugabyte SQL query layer is a fork of PostgreSQL 11.2's query layer. This query layer runs on DocDB, a distributed document store whose sharding, replication and …

Yugabyte PM here. The goal is to demonstrate that even SQL databases can now be scaled to 1M inserts per second, a feat that was previously reserved for NoSQL databases.

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 S…

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 …

Thanks for sharing these. Hadn’t heard of the first 2, so look fwd to reading them. We did review the Amazon Dynamo architecture (which is used in Dynomite) in depth but found it t…

Only if things were that simple :) Calvin avoids the need to track clock accuracy by making every transaction go through a single consensus leader which inherently becomes a single…

assume you are referring to https://en.wikipedia.org/wiki/NonStop_SQL -- was not aware of it so thanks for bringing it to attention. first impression is that it was a technology wa…

happy that you liked the post. as you could infer, this simplicity is by no means a magic bullet. there are always trade-offs depending on the database type you use as baseline for…

YugaByte DB product manager here. we have compared the Spanner and Calvin architectures in depth previously ( https://blog.yugabyte.com/google-spanner-vs-calvin-global-co... ). one…

YugaByte DB product manager here. Yes, CosmosDB and its underlying architecture were indeed not yet publicly available when we started the YugaByte DB project early 2016. However, …

YugaByte product manager here. The YCQL API which passes Jepsen has its roots in Cassandra Query Language but does not use Cassandra as its backend store. It’s backend store is Doc…