資料庫也需要適才適所
請不要把這類新聞直接當作某個結論，而是作為自我覺察與反思的起點。
Source: SQL Maxis: Why We Ditched RabbitMQ And Replaced It With A Postgres Queue
請 ChatGPT 幫忙摘要一下：
這篇文章討論了一家名為 SQL Max 的公司如何放棄使用 RabbitMQ，轉而使用 Postgres Queue。SQL Max 之前使用 RabbitMQ 來處理他們的資料傳輸和通訊，但是他們在使用過程中遇到了一些問題，例如 RabbitMQ 在處理大量資料時速度變慢、維護成本高等等。因此，他們開始探索其他的解決方案，最終他們選擇了 Postgres Queue。
在這篇文章中，作者詳細地介紹了 Postgres Queue 的優點，包括性能優越、易於維護、不需要額外的硬體支持等等。他們還提到了一些實現 Postgres Queue 的方法和工具，例如使用 pg-notify 模塊和使用 SQLAlchemy。
最後，作者還分享了 SQL Max 使用 Postgres Queue 後的一些好處和收穫，例如更高的效率、更容易維護和管理、更簡單的代碼實現等等。這篇文章提供了一個很好的案例，說明了為什麼在某些情況下，使用 Postgres Queue 可能是一個更好的解決方案。
RabbitMQ 在 Queue 的應用上，在市場上是很多人的首選，功能和效能公測上也都很優秀，只不過在現實的資料處理上，仍然需要更細微地考慮人與資料的問題。這篇分享剛好都描述到這些困擾，而這在每一個你所使用的資料庫都會有的問題。
人的問題在文章中有提到維護上的複雜度，而資料的問題則是處理了超過 Queue 作業需求的範圍，這使得開發上需要做出選擇。但就現階段的選擇而言，也不代表 PostgreSQL 可以完全取代 RabbitMQ 在 Queue 處理上的優勢。
文章裡最值得參考的是，實務決策思維的描述。
通常使用通用型資料庫（PostgreSQL）來實作 Queue 有幾個主要的考量：
- 開發/維護架構單純化
- 多樣化資料整合作業
- 應用服務專屬需求
其相對於 RabitMQ 類軟體的缺點為：
- 不夠輕量且高效率，如果只處理 Queue 的操作的話。
- 流量上限太低，同時連線數難以於 RabitMQ 相比。
然而，最後實作的是「人」，也許你看了這個案例有不同的想法，但只有參與其中的人可以衡量真實的利弊。
如果你的團隊也有類似的問題，也許可以問自己幾個問題：
- 我自己對每個實作方案的熟練度都相同嗎？
- 實作的人是我自己嗎？
- 需不需要考慮團隊整體的維運問題？
- 需不需要考慮主要決策者的喜好問題？
- 一定要同時處理多樣化資料嗎？
- 有沒有非技術考量？
- ……….
雖然有點大哉問，主要還是不脫「人」與「資料」。然而，每個團隊做出了各種不同的選擇，一定有其理由，每一個具體場景都可能是獨一無二的。
自我的覺察與反思，是在觀看他人案例時，比挑毛病更重要的事。
