There are many ways to handle ID generation in PostgreSQL. In this blog, we’ll demonstrate four ways to do so in Sequelize for PostgreSQL and YugabyteDB.
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.
YugabyteDB Managed is a fully managed offering of the YugabyteDB database. It delivers the power of distributed SQL with the ease of use of a database-as-a-service. It’s an effortless distributed SQL database. But what can it help you achieve? This blog walks through four reasons developers and enterprises alike will love YugabyteDB Managed.
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.
I’ve been working with distributed systems, platforms, and databases for the last seven years. Back in 2015, many architects began using distributed databases to scale beyond the boundaries of a single machine or server. They selected such a database for its horizontal scalability, even if its performance remained comparable to a conventional single-server database.
Now, with the rise of cloud native applications and serverless architecture, distributed databases need to do more than provide horizontal scalability.