<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Databases and Messaging on Ecostack</title>
    <link>https://ecostack.dev/categories/databases-and-messaging/</link>
    <description>Recent content in Databases and Messaging on Ecostack</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>© 2026 Sebastian Scheibe</copyright>
    <lastBuildDate>Mon, 17 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://ecostack.dev/categories/databases-and-messaging/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>PostgreSQL: Preventing Idle Connections From Accumulating After Deployments</title>
      <link>https://ecostack.dev/posts/postgres-idle-connections-after-deployments/</link>
      <pubDate>Mon, 17 Aug 2026 00:00:00 +0800</pubDate>
      
      <guid>https://ecostack.dev/posts/postgres-idle-connections-after-deployments/</guid>
      <description>The problem #   Last week, our PostgreSQL database started running out of connections. The connection limit was 100, but after a day or so the application could no longer open a new connection. When PostgreSQL returned a too many connections error, both production and the worker stopped working.
The confusing part was that the application pool was configured with a much smaller number of connections. Looking at pg_stat_activity, however, showed connections in both idle and idle in transaction states.</description>
      <media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://ecostack.dev/posts/postgres-idle-connections-after-deployments/featured.webp" />
    </item>
    
    <item>
      <title>gRPC vs RabbitMQ RPC: How Do They Compare for Microservices?</title>
      <link>https://ecostack.dev/posts/grpc-vs-rabbitmq-rpc-how-do-they-compare-for-microservices/</link>
      <pubDate>Sun, 19 Nov 2023 10:00:00 +0800</pubDate>
      
      <guid>https://ecostack.dev/posts/grpc-vs-rabbitmq-rpc-how-do-they-compare-for-microservices/</guid>
      <description>This article explores the differences between gRPC and RabbitMQ RPC, two leading frameworks in remote procedure calls (RPC) for microservices architecture.
Comparison overview #      Feature gRPC RabbitMQ RPC     Service Definition Yes (.proto file) No   Error Handling Predefined errors list Requires custom implementation   Security TLS, Token TLS, Username/Password   Orchestration Required Not necessary   Performance Fast Slower   Requires direct connection between server and client Yes No    What is RPC?</description>
      <media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://ecostack.dev/posts/grpc-vs-rabbitmq-rpc-how-do-they-compare-for-microservices/featured.webp" />
    </item>
    
    <item>
      <title>RabbitMQ Auto Reconnect Node.js</title>
      <link>https://ecostack.dev/posts/rabbitmq-auto-reconnect-nodejs/</link>
      <pubDate>Wed, 23 Aug 2023 22:50:10 +0800</pubDate>
      
      <guid>https://ecostack.dev/posts/rabbitmq-auto-reconnect-nodejs/</guid>
      <description>Problem #   You might have been in that situation, you just implemented a RabbitMQ consumer in Node.js and it works fine. Next thing you know, you are on-call and are woken up in the middle of the night because the queue is full and it is not being consumed.
On a closer look, you see the logs of the consumer and it says IllegalOperationError: Channel closed.
IllegalOperationError: Channel closed at ConfirmChannel.</description>
      <media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://ecostack.dev/posts/rabbitmq-auto-reconnect-nodejs/featured.webp" />
    </item>
    
  </channel>
</rss>
