Every SQL execution in PostgreSQL and therefore in YugabyteDB YSQL takes time to process. A common way to identify how much is time spent on processing is to use the pg_stat_statements view in the database. However, the time visible in pg_stat_statements might differ from the time a database client registers for the execution. Where does this difference come from? Let’s take a look.
In this blog, we will explore how YugabyteDB Change Data Capture (CDC) and open table formats like Apache Iceberg can be used to build data lakes in Amazon S3 using a single copy of the data and achieve low data ingestion latency while avoiding costly rewrites to support updates/deletes and schema evolution.
If you are designing your architecture for stateful edge applications, here are some key principles and design patterns you should be aware of.
YugabyteDB is built primarily to be a CP database per the CAP theorem. It supports two interfaces – YSQL for SQL workloads and YCQL for Cassandra-like workloads. In this blog, we will primarily talk about the YCQL interface. When an application interacts with the database using the YCQL interface, the writes are always consistent and reads are consistent by default. When this level of consistency is not required, YugabyteDB supports two other types of reads:
1.
…
This post is an in-depth look at the various techniques that applications needing low latency and high availability can leverage while using a geo-distributed SQL database like YugabyteDB so that the negative impacts of a high-latency, unreliable Wide Area Network (WAN) are minimized.