Thoughts on open source, cloud native and distributed databases
I am excited to announce that YugaByte has raised $16M in additional funding in a round led by Dell Technologies Capital and our previous investor Lightspeed Venture Partners. Combined with our previous funding of $8M, YugaByte has now raised $24M to solve one of the most challenging problems in operational databases today — bringing together NoSQL and SQL into a unified,
…
Read MoreResults from the 2018 Kubernetes Application Usage Survey should put to rest concerns enterprise users have had around the viability of Docker containers and Kubernetes orchestration for running stateful services such as databases and message queues. Its exciting to see that nearly 40% of respondents are running databases (SQL and/or NoSQL) using Kubernetes.
…
Read More
Modern user-facing apps, like E-Commerce and SaaS, frequently require features from multiple databases (broadly — SQL, NoSQL and a cache) to support their multi-workload needs. App developers are responsible for understanding and managing which pieces of data should be stored in which SQL and NoSQL database. Furthermore, the app is also responsible for moving data across the tiers (e.g.
…
Read MoreTeam YugaByte is delighted to announce the general availability of YugaByte DB 1.0!
It has been an incredibly satisfying experience to, in just two years, build and launch a cloud-scale, transactional and high-performance database that’s already powering real-world production workloads. I wanted to take a moment to share our journey to 1.0 and the road ahead.
…
Read MoreACID transactions are a fundamental building block when developing business-critical, user-facing applications. They simplify the complex task of ensuring data integrity while supporting highly concurrent operations. While they are taken for granted in monolithic SQL/relational DBs, distributed NoSQL/non-relational DBs either forsake them completely or support only a highly restrictive single-row flavor (see sections below). This loss of ACID properties is usually justified with a gain in performance (measured in terms of low latency and/or high throughput).
…
Read MoreKubernetes, the open source container orchestration engine that originated from Google’s Borg project, has seen some of the most explosive growth ever recorded in an open source project. The complete software development lifecycle involving stateless apps can now be executed in a more consistent, efficient and resilient manner than ever before. However, the same is not true for stateful apps — containers are inherently stateless and Kubernetes did not do anything special in the initial days to change that.
…
Read MoreA few of our early users have chosen to build their new cloud applications on YugaByte DB even though their current primary datastore is MongoDB. Starting with the v3.4 release in Nov 2016, MongoDB has made improvements in its sharding and replication architecture that has allowed it to be re-classified as a Consistent and Partition-tolerant (CP) database and move away from its Available and Partition-tolerant (AP) origins.
…
Read MoreThis is the first post in a series about building real-world, distributed cloud services using a transactional cloud database like YugaByte DB.
We are going to look at how to build a scalable chat or messaging application like Facebook Messages. This is close to heart to a number of us at YugaByte — we were the team behind the database platform that powers the Facebook Messages app.
…
Read More
One of our users was interested to learn more about YugaByte DB’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 YugaByte DB was designed well to handle this case with the optimal number of IOs to the disk subsystem.
…
Read More
The famed CAP Theorem has been a source of much debate among distributed systems engineers. Those of us building distributed databases are often asked how we deal with it. In this post, we dive deeper into the consistency-availability tradeoff imposed by CAP which is only applicable during failure conditions. We also highlight the lesser-known-but-equally-important consistency-latency tradeoff imposed by the PACELC Theorem that extends CAP to normal operations.
…
Read More
Source: