PgQue – une file d’attente Postgres sans bloat

• Installation avec un seul fichier SQL et fonctionnement (tick) uniquement avec pg_cron
• File de messages intégrée à Postgres qui réimplémente en pur PL/pgSQL l’architecture PgQ de l’époque de Skype, utilisable directement sur un Postgres managé sans extension C ni démon externe
• Élimine à la source les problèmes chroniques des files basées sur SKIP LOCKED — accumulation de dead tuples et charge VACUUM — grâce à des batchs basés sur des snapshots et à une rotation de tables par TRUNCATE, sans dégradation des performances même après plusieurs mois d’exploitation
• Prise en charge native du fan-out avec une structure de journal d’événements partagé + curseur indépendant par consommateur, similaire aux topics Kafka — plusieurs abonnés peuvent recevoir tous les événements de façon indépendante sans duplication des données
• La latence de livraison de bout en bout est d’environ 1 à 2 secondes avec la configuration par défaut (intervalle de tick + intervalle de polling), tandis que les appels individuels à send/receive/ack sont au niveau de la microseconde
• D’après les benchmarks préliminaires, insert en PL/pgSQL à ~86k ev/s, lecture côté consommateur à ~2.4M ev/s, et zéro augmentation des dead tuples lors d’un test continu de 30 minutes
• Basé sur une API SQL comme pgque.send(), pgque.receive(), pgque.ack(), il fonctionne avec tous les drivers Postgres, quel que soit le langage, notamment Python, Go et TypeScript
• Compatible avec les principaux fournisseurs de Postgres managé comme RDS, Aurora, Cloud SQL, AlloyDB, Supabase et Neon, sans build séparé ni validation du fournisseur
• Séparation des permissions intégrée via trois rôles (pgque_reader, pgque_writer, pgque_admin), sans besoin de superuser pour les utilisateurs applicatifs
• Si PgQ lui-même a été éprouvé en production pendant plus de 10 ans à l’échelle de centaines de millions d’utilisateurs chez Skype, PgQue en tant que produit en est encore à ses débuts (v0.1)
• Licence Apache-2.0