My first test of Aurora DSQL focuses on read and write latency using an existing Java application designed for a PostgreSQL-compatible database. I utilize the )
us-east-1
us-east-2
us-west-2
us-east-1 (N. Virginia) Linked cluster
9.04 ms
20.55 ms
71.46 ms
us-east-2 (Ohio) Linked cluster
19.76 ms
9.52 ms
58.04 ms
us-west-2 (Oregon) Witness
64.12 ms
55.42 ms
5.81 ms
I'll connect in us-east-1 (N. Virginia) to the endpoint in the same region.
CloudShell in eu-east-1
I upgrade AWS CLI to access DSQL that was released recently, I install Java and download the
This confirms the round-trip latency (RTT) I got from CloudPing information.
SqlInserts on Aurora DSQL
With this all set, I can run the SqlInserts (Sample key-value app built on PostgreSQL with concurrent readers and writers. The app inserts unique string keys) workload of yb-sample-apps.jar:
This is the simplest workload scenario: inserting data from the node where the leader is located, without using any secondary indexes. Because of this, we only need to wait for one Raft consensus. If this insert were a global transaction (because of secondary indexes or referential integrity), it would have introduced an additional multi-region synchronization in YugabyteDB.
In this series of blog posts, I will run various workloads and compare them to YugabyteDB out of curiosity, as it helps me understand the architecture. The core principle is similar: a Distributed SQL database that is horizontally scalable and delivers high performance, even in multi-region scenarios. However, there are trade-offs in several areas, including performance, availability, PostgreSQL compatibility, and multi-cloud capabilities.
PSQL and EXPLAIN ANALYZE with Aurora DSQL
To make it easier to reproduce, I run a similar insert from psql connected to the endpoint in the same region:
As expected, the statement's execution time in Aurora DSQL is quick due to local reading and writing. The total elapsed time includes the commit, which synchronizes the Aurora DSQL journal with other regions (requiring one round-trip time, the RTT to the closest region being 10 milliseconds here), and a brief wait to ensure that subsequent reads can recognize the committed changes.
PostgreSQL doesn't provide an EXPLAIN ANALYZE from the commit, but given that Aurora DSQL does everything at commit, I hope that AWS will provide more insight on what happens (time to sync + time waiting) when more instrumentation comes.
Stay tuned for more posts on this series about Aurora DSQL. You can follow me on , or LinkedIn to receive updates on new posts.
Vollständiger Original-Bericht
Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR