YugaByte Company and Database Update – Aug 3, 2018
In case you missed the news earlier this Summer, YugaByte raised an additional $16M of funding from Dell Technologies Capital and our previous investor Lightspeed Venture Partners. With the additional funding, we are accelerating investments in engineering, sales, and customer success to scale our support for enterprises building business-critical applications in the cloud. So, as you’d expect…
Current open positions in Sunnyvale, CA include:
- Developer Advocate
- Software Engineer – Core Database
- Software Engineer – Cloud Infrastructure
- Software Engineer – Full Stack
Our team consists of domain experts from leading software companies such as Facebook, Oracle, Nutanix, Google and LinkedIn. We have come a long way in a short time but we cannot rest on our past accomplishments. We need your ideas and skills to make us better at every function that is necessary to create the next great software company. All while having tons of fun and blazing new trails!
It was great to meet many of our customers and community members at Google Next last week. Especially interesting were all the great conversations we had with developers (including Google engineers) about the hard problems related to building distributed databases. Also, congratulations to the raffle winners of our Google Daydream VR headsets:
- Andre Zoutte
- Richard Clark
- Singaram Ragunathan
If you were at Google Next, you probably sat through a talk or two about Cloud Spanner. How does YugabyteDB compare? In a nutshell:
- YugabyteDB is open source, Apache 2.0 licensed
- Supports Google Cloud, AWS, Azure, Kubernetes, Docker and private data centers
- Redis, Cassandra and PostgreSQL compatible APIs for reading and writing data.
- Implementing Distributed Transactions the Google Way: Percolator vs Spanner
- Practical Tradeoffs in Google Cloud, Azure Cosmos DB and YugabyteDB
- New to Google Cloud Databases? 5 Areas of Confusion
Earlier this year, one of our users was interested to learn more about YugabyteDB’s behavior for a random read workload where the data set does not fit in RAM and queries need to read data from disk (i.e. an uncached random read workload). The intent was to verify if YugabyteDB was designed well to handle this case with the optimal number of IOs to the disk subsystem.
This post was a sneak peak into just one of the aspects of YugabyteDB’s innovative storage engine, DocDB, which supports very high data densities per node. This is something that helps keep your server footprint and AWS (or relevant cloud provider) bills low! If you’re interested in the internals of DocDB, you can check out our GitHub repo.
We’ve already tested YugabyteDB’s ability to scale to millions of reads and writes and completed linear scalability testing on clusters of up to 50 nodes in size. In terms of data densities, we have tested up to 4.5TB of data per node (on c4.4xlarge nodes with 16-vcpus/30GB RAM).
We are currently running Jepsen tests against YugabyteDB as part of our CI/CD pipeline. As a part of our Jepsen test suite, we run different workloads such as single key updates, single row ACID transactions and multi-row ACID transactions while simulating a number of failures scenarios. The failures scenarios include process failures, network partitions and clock skew. Expect a blog post detailing these results soon!
We are excited to announce that YugabyteDB 1.1 will be going GA in a few weeks! Here’s what’s new that is shipping in 1.1:
- Distributed transactions
- Secondary indexes
- JSON data type
- Redis follower reads
- Authentication and TLS Encryption on the wire
- Plus features that will be ready for beta testing, along with bug fixes and performance enhancements
If you are interested in seeing a demo or evaluating YugabyteDB 1.1 before it goes GA, contact us.