Amazon recently launched Aurora DSQL, a new distributed SQL database that validates the growing importance of distributed SQL and introduces unique architectural features tied to the AWS infrastructure. This blog examines Aurora DSQL’s PostgreSQL compatibility, architectural distinctions, concurrency control, multi-region capabilities, and positioning relative to YugabyteDB in the evolving database landscape.
Peak events like Black Friday sales, record-breaking concerts, and unpredictable freak events like adverse weather and cloud outages, are pushing legacy database technology’s scalability and resilience limits.
With even more frequent and extreme peak events and freak events likely in the years to come, discover how distributed SQL can help!
The cloud revolution, initially promising for application scaling, falls short in database scalability, facing challenges with concurrent user management and processing. To truly harness cloud benefits and meet peak demands, organizations must consider horizontally scalable, cloud-native databases over traditional, monolithic SQL systems.
Distributed SQL offers greater scalability, availability, and geo-distribution of data compared to PostgreSQL, but it is important to understand the differences in behaviors between the two systems in order to make the most of your distributed SQL database.
This edition of the Distributed SQL Tips and Tricks blog looks how and why Yugabyte handles efficient row retrieval using a primary key, as well as the implications of not having one.
When considering replication options between YugabyteDB clusters, you have two options—xCluster async replication or setting up Kafka. Learn the when and how and why to both choices.
This edition of the Distributed SQL Tips and Tricks blog looks at YugabyteDB’s support for composite keys for tables (as well as secondary indexes).
In YugabyteDB you can use sharding and partitioning, so it can be confusing. In this blog post, we explore the differences (and similarities) between them and when each should be used.
This blog explores YugabyteDB’s ability to propagate client requests to surviving nodes when a node becomes unavailable. The behavior depends on factors such as client connection method, driver used, and connection pooling.
Setting the number of shards/tablets in your YugabyteDB cluster is dependent on your table size and activity, and while it is hard to gauge the exact number, here are some high-level suggestions.
