Let’s see how to capture pg_stat_statements from all the nodes in a persistent table to use for analysis. The data can then be stored in YugabyteDB tables, accessible from any node unless purged. Want to see how it can be done?
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.
Finding one-to-one mapping of the differences between monolithic and cloud-native databases is difficult.
In this blog, we compare YugabyteDB and Oracle (RAC, Data Guard) via availability objectives.
This should help you understand how Oracle MAA options map to YugabyteDB’s intrinsic features when considering migration projects.
In Java development, garbage collection is a routine task. Applications generate garbage all the time. And that garbage is meticulously cleaned out by CMS, G1, Azul C4 and other types of collectors. Basically, our applications are born to bring value to this world, but nothing is perfect—including our applications that leave litter in the Java heap.
However, the story doesn’t end with the Java heap. In fact, it only starts there. Let’s take the example of a basic Java application that uses a relational database—such as PostgreSQL—and solid state drives (SSDs) as a storage device.
…
In this blog, we’ll discover how to publish data to a Kafka topic and then read those messages to another sink, in this case a PostgreSQL database.
In this blog post, we will stream data to downstream databases leveraging YugabyteDB’s Change Data Capture (CDC) feature introduced in YugabyteDB 2.13. This will publish the changes to Kafka and then stream those changes to databases like MySQL, PostgreSQL, and Elasticsearch.
Recently, I came across a sample e-commerce application that demonstrates how to use Next.js, GraphQL engine, PostgreSQL, and a few other frameworks to build a modern web application. The application supports basic e-commerce capabilities such as product inventory and order management, recommendation system, and checkout function. This made me curious as to how much effort it would take to complete a retail application migration from an on-premise to cloud native solution. So I decided to try.
In the first post in this series, we covered how to secure YugabyteDB’s internal RPC protocol using the TLS encryption protocol, also referred to as server-to-server encryption in transit. In this post, we secure the communication between SQL clients and the PostgresQL query interface of YugabyteDB, also called client-to-server encryption in transit.
YugabyteDB—a 100% open source, distributed SQL database built to accelerate cloud native agility—stores important user and customer data at an organization.
…
ybio is a PL/pgSQL based load generator for PostgreSQL and YSQL. This YugabyteDB-specific IO testing toolkit performs flexible IO testing to specific parts of the YugabyteDB infrastructure with no client installation. And because this toolkit is PL/pgSQL-based, it can also work on native PostgreSQL.
ybio is strongly inspired by Kevin Closson’s SLOB and pgio. Yugabyte Developer Advocate Franck Pachot took pgio and turned it into ybio.
…
Last November, we announced the general availability of YugabyteDB 2.11, a major release which extends PostgreSQL compatibility of the open source distributed SQL database. All these features are readily available in this stable release for any production environment.
In addition to making these features GA, YugabyteDB 2.12 introduces several new capabilities and significant improvements towards seamless security and better manageability.
Building customer trust is a top priority at Yugabyte.
…
