Search: yugabyte intern

Distributed PostgreSQL on a Google Spanner Architecture – Query Layer

Distributed PostgreSQL on a Google Spanner Architecture – Query Layer

Our previous post dived into the details of the storage layer of YugabyteDB called DocDB, a distributed document store inspired by Google Spanner. This post focuses on Yugabyte SQL (YSQL), a distributed, highly resilient, PostgreSQL-compatible SQL API layer powered by DocDB. A follow-up post will highlight the challenges faced and lessons learned when engineering such a database.

YSQL, Distributed PostgreSQL Made Real

Yugabyte SQL (YSQL) is a distributed and highly resilient SQL layer,

Read more

Enhancing RocksDB for Speed & Scale

Enhancing RocksDB for Speed & Scale

As described in our previous post “How We Built a High Performance Document Store on RocksDB?”, YugabyteDB’s distributed document store (DocDB) uses RocksDB as its per-node storage engine. We made multiple performance and data density related enhancements to RocksDB in the course of embedding it into DocDB’s document storage layer (figure below). These enhancements are distributed as part of the YugabyteDB open source project. The goal of this post is to deep dive into these enhancements for the benefit of engineering teams interested in leveraging RocksDB beyond its original design intent of a fast monolithic key-value store.

Read more

How We Built a High Performance Document Store on RocksDB?

How We Built a High Performance Document Store on RocksDB?

This blog post was co-authored by Mikhail Bautin and Kannan Muthukkaruppan

RocksDB is a popular embeddable persistent key-value store. First open sourced by Facebook in 2012 as a fork of the Google LevelDB project, it has been adapted over the years to a wide range of workloads including database storage engines and application data caching.

In this post, we explain our rationale for selecting RocksDB as a foundational building block for YugabyteDB.

Read more

7 Issues to Consider When Evaluating FoundationDB

7 Issues to Consider When Evaluating FoundationDB

FoundationDB enjoys a unique spot in the transactional NoSQL space given its positioning as a basic key-value database that can be used to build new, more application-friendly databases. Given that many of the guarantees provided by its core engine (such as multi-shard ACID transactions and high fault tolerance) are similar to those provided by the YugabyteDB database, our users often ask us for a comparison. These users are essentially trying to understand whether they should build their app directly using one of the three YugabyteDB APIs or should they explore/build a new database layer on FoundationDB first.

Read more

Rise of Globally Distributed SQL Databases – Redefining Transactional Stores for Cloud Native Era

Rise of Globally Distributed SQL Databases – Redefining Transactional Stores for Cloud Native Era

At last month’s KubeCon + CloudNativeCon in Seattle, the single biggest change from previous container-related conferences was the excitement among the end user companies around their adoption of Kubernetes and the associated cloud native infrastructure ecosystem. The CNCF End User Community page today lists 50+ enterprises and 21+ case studies including those from industry bellwethers such as Capital One, Netflix, Nordstrom and Pinterest. There is a common adoption pattern among all these case studies —

Read more

Why are NoSQL Databases Becoming Transactional?

Why are NoSQL Databases Becoming Transactional?

The SQL vs. NoSQL database split emerged in 2006-2007, but NoSQL’s compromises led developers to continue using SQL/RDBMS for critical workloads. However, recent changes in the NoSQL world have seen the adoption of ACID transactions, which were previously absent, and this post aims to inform architects of these changes and why they are happening now.

Read more

Google Spanner vs. Calvin: Is There a Clear Winner in the Battle for Global Consistency at Scale?

Google Spanner vs. Calvin: Is There a Clear Winner in the Battle for Global Consistency at Scale?

Prof. Daniel Abadi, lead inventor of the Calvin transaction management protocol and the PACELC theorem, wrote a thought-provoking post last month titled “NewSQL database systems are failing to guarantee consistency, and I blame Spanner”. The post takes a negative view of software-only Google Spanner derivative databases such as YugabyteDB and CockroachDB that use Spanner-like partitioned consensus for single shard transactions and a two phase commit (2PC) protocol for multi-shard (aka distributed) ACID transactions.

Read more

Explore Distributed SQL and YugabyteDB in Depth

Discover the future of data management.
Learn at Yugabyte University
Get Started
Browse Yugabyte Docs
Explore docs
PostgreSQL For Cloud Native World
Read for Free