Comparing Synchronous and Asynchronous Access to Postgres

DZone 's Guide to

Comparing Synchronous and Asynchronous Access to Postgres

In this article, we compare asynchronous and synchronous access to PostgreSQL from Quarkus with Java-based microservices.

· Microservices Zone ·
Free Resource

Quarkus supports imperative as well as reactive programming styles. In this article, I compare access times to Postgres from a Java-based microservices developed with Quarkus. For synchronous invocations, Panache is used, for asynchronous access Vert.x Axle.

I’ve created a sample application that comes with the cloud-native-starter project. The "articles" microservice accesses the database running in Kubernetes. To keep the scenario simple, only one REST API is tested, which reads articles from Postgres.

Application architecture

Application architecture

There are two implementations of the articles service:

  1. Imperative/synchronous: The REST endpoint has been implemented with JAX-RS (synchronous). The service reads articles from Postgres via Panache (see Quarkus guide Simplified Hibernate ORM with Panache).
  2. Reactive/asynchronous: The REST endpoint has been implemented with Vert.x, CompletionStage, and CompletableFuture asynchronously. The service reads articles asynchronously from Postgres via Vert.x Axle (see Quarkus guide Reactive SQL Clients).

The reactive stack of this sample provides response times that take less than half of the time compared to the imperative stack: Reactive: 142 ms (0:42 min total) – Imperative: 265 ms (1:20 min total). Check out the documentation for details.

While this scenario is not necessarily representative, I think it demonstrates nicely the efficiency of reactive programming.

I’ve run a second performance test where a more complete cloud-native application is tested. Check out the documentation.

Synchronous Access via Panache

Panache is basically an extension of JPA, which makes persistence really easy. After you’ve defined the dependencies and the configuration in application.properties, you can define the entity (see code):


Panache comes with built-in convenience methods to access databases — listAll to read all articles (see code):


Asynchronous Access With Vert.x Axle

After you’ve defined the dependencies and the configuration in application.properties, the articles can be read from the database via the following code:


When using the reactive approach, as far as I know, the schema needs to be created programmatically. Additionally, the data from the databases need to be converted into Java objects manually. Hopefully these two areas will be simplified similarly to how this is done with JPA and Panache.

Closing Thoughts

All samples of this article are included in the open-source project cloud-native-starter. Check it out to see the code in action.

This article is part of a series. Read the other articles of this series to learn about reactive programming:

asynchronous ,big data ,cloud ,database ,java ,postgres ,synchronous

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}