YugabyteDB 2.19.2 introduces full support for Read Committed Isolation with Wait-On-Conflict, essential for PostgreSQL users looking to seamlessly lift-and-shift applications to a distributed environment. This feature ensures parity with PostgreSQL while leveraging the scale and resilience of YugabyteDB, simplifying the transition for users.
YugabyteDB 2.19 introduces a revolutionary built-in Connection Manager, transforming PostgreSQL’s well-documented connection challenges into strengths. The enhanced manager boosts connection creation speeds up to 20x and supports up to 5x more connections, all while maintaining consistent throughput.
Discover why YugabyteDB doesn’t support PostgreSQL extensions pg_repack and pg_buffercache. While YugabyteDB leverages the Postgres query layer, its unique approach to the storage layer makes certain extensions unnecessary.
Introducing PgCompute—a client-side extension for PostgreSQL aimed at revitalizing the use of database functions by allowing developers to create and optimize them seamlessly within their preferred IDE and programming language.
PostgreSQL offers robust features but has certain limitations in scalability, replication, resilience (and more). YugabyteDB addresses these issues through distributed design, storage efficiency, and transaction handling, providing a comprehensive solution when high availability, ACID, and scale are mandatory.
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.
YugabyteDB uses LSM Tree / SST Files to minimize the risk of data corruption, in contrast to PostgreSQL’s method. This approach, coupled with independent compactions and checksum verification, enhances data integrity.
Discover how to best achieve high availability and disaster recovery using two data centers. This blog compares traditional monolithic databases with distributed SQL, and then discusses how it is all possible using YugabyteDB with cross-cluster replication capabilities.
See how how easy it is to use YugabyteDB Voyager to migrate a Node.js application backed by a single-node PostgreSQL database to a distributed YugabyteDB database cluster.
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.