Handling Automatic ID Generation in PostgreSQL with Node.js and Sequelize
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.
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.
In a previous blog, we developed an application-level sharding layout to avoid hotspots. With that layout in mind, where order is maintained within each shard, let’s discuss how to design a query to return data with pagination while maintaining the global ordering.
This post walks you through how to quickly build an interactive data analytics dashboard in Power BI using the data stored in your YugabyteDB database and specify the storage mode of a table.
Some data model choices in distributed databases cause data to grow in one node before it moves to another node. This will cause one node to become a hotspot for reads and writes. This article explains how to avoid that.
To illustrate how to build a geo-distributed application, we will use as an example a Slack-like messaging app. This step-by-step guide starts with the distributed application and API layers, continues on to the distributed SQL database, and finishes with the need/purpose of the global cloud load balancer.
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?
YugabyteDB for Python (Django) app can achieve high availability (HA) and handle a cloud outage. To demonstrate this, we will simulate an outage in Google Cloud Platform (GCP) on one of the Yugabyte database nodes to see how YugabyteDB handles the downtime.
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.
As you look to build a streaming application that scales, there are many database options to choose from. If you’re looking for a high-performance database that can handle large-scale data, YugabyteDB,
is a great option. In this blog, we will build an application with YugabyteDB and Django, using the PubNub market order data stream. You will see how you can use YugabyteDB and Django to make an application that subscribes to the PubNub Market Orders Stream, stores these trades in YugabyteDB, and displays them in real-time.
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.