CloudNativePG makes it easy to get started with PostgreSQL on Kubernetes, but is constrained by the inherent limitations of PostgreSQL’s monolithic architecture. This blog explores how each database approaches high availability, scalability, and cloud-native architecture, and details why a truly distributed architecture matters in modern application development.
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.
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.
Yugabyte SQL is based on a reuse of PostgreSQL’s native query layer.
…
At Yugabyte, we welcome competition and criticism. We believe these aspects are essential to the wide adoption of a business-critical, fully open source project like YugabyteDB. Specifically, constructive criticism helps us improve the project for the benefit of our large community of users. Engineers at Cockroach Labs posted their analysis of how CockroachDB compares with YugabyteDB a few months ago. We thank them for taking the time to do so.
…
In this post, we compare distributed SQL databases against NewSQL databases to better understand their differences and know when you should use either.
