Learn to build a scalable AI application with Azure OpenAI Service and YugabyteDB. See how to interface with Azure’s GPT and Embeddings models, embedding storage in YugabyteDB and conducting similarity searches in distributed clusters.
Blogs by: Denis Magda
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.
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.
In an earlier blog, we broke down the definition of geo-distributed apps. So now let’s compare and contrast geo-distributed apps those apps that are deployed within a single data center or availability zone. A good way to make this comparison to understand the differences and find the similarities is to drill down into the architecture.
So what is a geo-distributed app? It is generally defined as an app that spans multiple geographic locations for high availability and resiliency. However, Iet’s expand (and then break down) that definition for a better understanding.
This blog post explores the most popular multi-region database deployment options by designing a data layer for a Slack-like corporate messenger.
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.
A modern GraphQL API layer for cloud native applications needs to possess two characteristics: horizontal scalability and high availability.
Horizontal scalability adds more machines to your API infrastructure, whereas vertical scalability adds more CPUs, RAM, and other resources to an existing machine that runs the API layer. While vertical scalability works to a certain extent, the horizontally scalable API layer can scale beyond the capacity of a single machine.
When it comes to high availability,
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.