In this excerpt from the recent white paper, Migrating From Monolithic to Cloud Native Operational Databases, we look at three of the challenges faced by companies using the current generation of NoSQL databases and why distributed SQL may be a better choice.
It’s a common misconception that NewSQL and distributed SQL databases are the same. They’re not. Even though they’re both an evolution in the transactional database, there are significant differences. Distributed SQL adoption is growing because companies face new challenges that cannot be easily addressed with NoSQL, SQL, or NewSQL databases. Let’s look at five of them.
We are excited to announce that Yugabyte has closed $188 million in oversubscribed Series C funding. Sapphire Ventures led the round with participation from Alkeon Capital, Meritech Capital, and Wells Fargo Strategic Capital, as well as existing investors Lightspeed Venture Partners, 8VC, Dell Technologies Capital, Wipro Ventures, and others. This round comes seven months after our previous round in March 2021,
…
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.
…
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.
This post aims to help application developers understand the choice of SQL vs. NoSQL in the context of the data modeling needs of an application.
Our post Getting Started with Distributed Backups in YugabyteDB details the core architecture powering distributed backups in YugabyteDB. It also highlights a few backup/restore operations in a single region, multi-AZ cluster. In this post, we perform distributed backups in a multi-region YugabyteDB cluster and verify that we achieve performance characteristics similar to those observed in a single region cluster.
We configured a 9 node cluster with 3 availability zones across 2 regions and repeated the benchmark introduced in the post.
…
YugabyteDB is a distributed database with a Google Spanner-inspired strongly consistent replication architecture that is purpose-built for high availability and high performance. This architecture allows administrators to place replicas in independent fault domains, which can be either availability zones or racks in a single region or different regions altogether. These types of multi-AZ or multi-region deployments have the immediate advantage of guaranteeing organizations a higher order of resilience in the event of a zone or region failure.
…
This post describes how you can run Presto queries on YCQL API as well as join data across the YCQL and YSQL APIs.
MongoDB’s “schemaless” JSON data modeling was initially attractive to web app developers looking to escape the constraints of traditional relational databases, but issues with data durability and ACID transactions have been a consistent challenge. While the recent MongoDB 4.0 release includes multi-document transaction support, this post explores where the platform falls short for transactional, high performance apps.
