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.
Compare and contrast
In an earlier blog, we broke down the definition of geo-distributed apps. So now let’s compare and contrast geo-distributed apps those apps that are deployed within a single data center or availability zone. A good way to make this comparison to understand the differences and find the similarities is to drill down into the architecture.
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.
Getting the total row counts of data in tables across various dimensions (per-table, per-schema, and in a given database) is a useful SQL technique to have in your toolkit. This blog post will guide you to obtain per-table row counts of all tables in PostgreSQL and YugabyteDB. This can serve as a first sanity check after migrating an application with pre-existing data from PostgreSQL to YugabyteDB.
This blog post also outlines how to get the following row counts broken down per table in a schema,
Earlier this week, Yugabyte CTO Karthik Ranganathan presented the live webinar: Evaluating CockroachDB vs YugabyteDB, with a spotlight on comparing PostgreSQL features, architecture, and the latest performance benchmarks between the two databases. We were delighted to see such interest in the topic, dive deeper into some of the topics we raised in parts 1 and parts 2 of the blog series, Bringing Truth to Competitive Benchmark Claims – YugabyteDB vs CockroachDB, and answer questions from the audience.
This post explores the compatibility of YugabyteDB with Oracle and PostgreSQL by examining 15 different Oracle features and their PostgreSQL equivalents highlighted in Roland Takacs’ blog post “Oracle vs PostgreSQL: First Glance.” As a PostgreSQL-compatible distributed SQL database, YugabyteDB offers a broad range of SQL features, making it an interesting choice for those looking to migrate from Oracle to a modern tech stack.
In part 1 of this blog series, we highlighted multiple factual errors in the Cockroach Labs analysis of YugabyteDB. In this second post we provide the next layer of detail behind YugabyteDB’s architecture, with an emphasis on comparing it to that of CockroachDB’s.
Contents of this post
- Query layer – reusing PostgreSQL
- Storage layer – engineered for performance at scale
- A deep dive into performance at large data sizes
- Results at a glance
- Take one – loading 1 billion rows with 64 threads
- CockroachDB: data load slowdown with data size increase
- Using multiple disks for a single large table
- Ranges vs tablets – architectural differences
- Impact of compactions on query performance
- YugabyteDB: 1B data load completed successfully
- Backpressure user requests when overloaded
- Take two – loading 450 million rows with 32 threads
- Detailed YCSB results
- Understanding performance in distributed SQL
Yugabyte SQL is based on a reuse of PostgreSQL’s native query layer.
One of the flagship features of the Yugabyte distributed SQL database is the PostgreSQL-compatible YSQL API. Let’s take a look at the performance and scalability of YSQL and compare it to two other PostgreSQL-compatible databases—Amazon Aurora PostgreSQL and CockroachDB.