Analyse Comparative de Performance : PostgreSQL face à Valkey (Redis) et à l'In-Memory

Christophe Lecroq • Architecte & Lead Dev Go

📁 Benchmarkings • 📅 27 juillet 2026 • ⏱️ 13 min de lecture •v1.0

#PostgreSQL#Valkey#Caching#Benchmark#P99Latency

1. Contexte & Problématique Architecturales

L'ajout d'une brique de cache clé-valeur distribuée en mémoire vive (ex: Valkey, Redis) est devenu un réflexe d'architecture dans les systèmes modernes. Si ce modèle offre une faible latence, il introduit un coût opérationnel et des contraintes concrètes :

• Exploitation & Observabilité : Déploiement, monitoring, patching et gestion de la haute disponibilité (failover, réplication) d'un cluster supplémentaire.
• Saut Réseau (Network Hop) : Latence inter-processus TCP, gestion des pools de connexions et surcoût de sérialisation.
• Cohérence des Données : Complexité d'invalidation, gestion des fenêtres de désynchronisation (stale cache) et risques de race conditions.

D'un point de vue strict d'ingénierie, la question se pose :

Dans quelle mesure un serveur PostgreSQL configuré à l'état de l'art peut-il absorber un workload de cache clé-valeur à haut débit et quelles sont ses limites physiques explicites ?

Pour apporter une réponse factuelle, le banc de test benchmark-caching évalue le débit (RPS), la mémoire et la distribution des percentiles de latence (P50, P90, P95, P99) sur quatre architectures de stockage sous une charge soutenue de 250 workers concurrents.

2. Architecture du Banc de Test & Isolation Système

Le runner du benchmark exécute un microservice Go optimisé (fasthttp), exposant des endpoints d'API REST standardisés (/get, /set) reliés aux différents backends :

• ⚡ Injection de Charge (Vegeta • 250 Workers)
  • 🚀 Serveur d'Exécution (Go fasthttp • Port 8080)
    • 💡 In-Memory (Otter v2 • In-Process)
    • 🔴 Valkey 9.1 (Fork Redis • Pool TCP)
    • 🐘 Standard Postgres (UUIDv7 • 10M Lignes)
    • ⚡ Optimized Postgres (UNLOGGED • VTProto)

Isolation Système & Contraintes CGroups Linux

Afin de garantir des mesures étanches et éliminer la variabilité due à la contention CPU/RAM :

• Serveur d'Exécution Go : Bridé via CGroups systemd à 4 CPU (GOMAXPROCS=4) et 10 Go de RAM (GOMEMLIMIT=10GiB).
• PostgreSQL & Valkey : Confinés dans des tranches systemd distinctes (CPUQuota=200%, MemoryMax=4G).
• Tuning Réseau Kernel Linux : Réutilisation rapide des sockets TCP (net.ipv4.tcp_tw_reuse=1) et extension de la plage de ports éphémères (1024-65535) pour éviter l'épuisement des sockets en état TIME_WAIT.

3. Détail des 4 Configurations Analysées

1. 💡 In-Memory (Otter v2)

   • Mécanisme : Cache applicatif in-process utilisant github.com/maypok86/otter/v2 (S3-FIFO, verrous minimisés, TTL automatique).
   • Rôle : Établit la borne supérieure théorique de la machine (zéro appel réseau, zéro I/O).

2. 🔴 Valkey 9.1 Key-Value Store

   • Mécanisme : Instance Valkey standalone sollicitée via un pool de 2 500 connexions TCP réutilisables.
   • Payload & Clés : Payloads binaires Protobuf sérialisés via vtprotobuf et clés ULID Base32 (github.com/oklog/ulid/v2).

3. 🐘 Standard PostgreSQL (UUID v7)

   • Mécanisme : Table relationnelle classique (users_standard) de 10 000 000 de lignes (~1,3 Go) dont le Working Set réside dans les shared_buffers et le Page Cache OS.
   • Indexation : Clé primaire UUID v7 séquentielle de 16 octets. Écritures synchrones avec WAL.

4. ⚡ Optimized PostgreSQL (UNLOGGED / VTProto)

   • Mécanisme : Table non journalisée (UNLOGGED) de 100 000 clés volatiles actives, supprimant l'écriture du journal de transaction (WAL).
   • Payload & Optimisations : Données sérialisées en bytea Protobuf, réserve d'espace de page (fillfactor = 70) favorisant les mises à jour Heap-Only Tuples (HOT) et nettoyage asynchrone (FOR UPDATE SKIP LOCKED).

4. Stratégies d'Optimisation Bas Niveau & Décryptage Technique

A. Sérialisation Zéro Allocation (vtprotobuf)

Le recours standard à la réflexion de encoding/json ou du package proto officiel génère des allocations sur le Heap à chaque appel, provoquant de la pression sur le Garbage Collector (GC) sous forte charge.

B. Configuration Système de PostgreSQL (postgresql.conf)

Pour maximiser l'efficacité du moteur en mode cache, la configuration a été ajustée :

• shared_buffers = 25% de la RAM : Allocation du cache de blocs principal de Postgres.
• effective_cache_size = 50% à 75% de la RAM : Indication au planificateur comptabilisant les tampons Postgres et le Page Cache du noyau Linux.
• work_mem = 16MB à 64MB : Mémoire par opération de tri/hachage pour prévenir les débordements sur disque.
• max_wal_size = 4GB à 16GB & checkpoint_completion_target = 0.9 : Étalement des écritures d'arrière-plan pour éviter les pics de latence P99 lors des checkpoints.
• Tables UNLOGGED & HOT Updates (fillfactor=70) : Suppression des fsync du WAL et optimisation du placement des n-uplets.

C. Configuration de Valkey (valkey.conf)

• maxmemory-policy = allkeys-lru : Éviction automatique selon l'algorithme des clés les moins récemment utilisées.
• io-threads = 2 à 4 & io-threads-do-reads = yes : Déchargement du parsing RESP et de la lecture socket sur des threads secondaires.
• Désactivation de la persistance : save "" (pas de snapshots RDB) et appendonly no (pas de AOF) pour évaluer le moteur en mémoire pure.

5. Résultats Mesurés : Endurance en Lecture GET (10 Min / 10M Lignes)

Endurance soutenue pendant 10 minutes sous 250 workers concurrents. Écarts mesurés par rapport à la référence PostgreSQL Standard.

Analyse Factuelle des Lectures

• Hiérarchie des débits : Le cache in-process Otter v2 atteint le plafond de la machine (106k req/s). Valkey le suit à 77k req/s. PostgreSQL s'établit à ~54 000 req/s, soit 70 % des capacités de Valkey.
• Impact de la taille de la table : Passer d'une table dédiée de 100k clés à une table relationnelle de 10M de lignes (~1,3 Go) ne dégrade pratiquement pas le débit de Postgres (53,7k vs 53,3k req/s).
• Comportement des percentiles : L'ensemble des architectures maintient une latence P99 sous la barre des 10 ms.

6. Résultats Mesurés : Écritures SET (Seeding 100 000 Clés)

Insertion et mutation massives de 100 000 clés. Écarts mesurés par rapport à la référence PostgreSQL Standard.

Analyse Factuelle des Écritures

• Le goulot d'étranglement de la persistance : En mode classique avec WAL synchrone (fsync), PostgreSQL est limité à 2 754 req/s avec une latence P99 de 173,8 ms, illustrant le coût de la durabilité ACID complète sur disque SSD.
• Rôle du mode UNLOGGED (+10,6x) : En désactivant le journal de transaction pour les données volatiles, PostgreSQL atteint 29 405 req/s et ramène sa latence P99 à 32,5 ms.
• Écart persistant avec le Key-Value : Malgré l'option UNLOGGED, Valkey conserve un débit d'écriture 2,3x supérieur (68,9k req/s) grâce à son architecture in-memory sans gestion de verrous de lignes (row locks) complexes.

7. Matrice Comparative des 4 Solutions Principales

8. Recommandations d'Architecture & Typologies d'Usage

9. Conclusion

Les données chiffrées apportent un éclairage pragmatique sur l'organisation des architectures de stockage :

1. Efficience des lectures : Sur un Working Set dimensionné en RAM (10M de lignes / 1,3 Go), PostgreSQL fournit ~54 000 req/s (70 % des performances de Valkey) avec des latences de queue similaires (P99 de 8,58 ms vs 6,78 ms).
2. Écritures et limites physiques : Face à des rafales d'écritures volatiles, PostgreSQL avec WAL standard constitue un goulot d'étranglement (2,7k req/s). L'option UNLOGGED permet d'atteindre 29,4k req/s, mais reste en dessous d'un moteur in-memory dédié (68,9k req/s pour Valkey).
3. Arbitrage d'architecture : Pour les applications dont la charge en lecture ne dépasse pas 50 000 req/s, interroger directement une base PostgreSQL correctement indexée permet de réduire la complexité système, d'éviter la maintenance d'un cluster secondaire et de garantir la cohérence des données. L'introduction d'une brique comme Valkey se justifie dès lors que les seuils de trafic réseau ou d'écritures massives dépassent les limites physiques du SGBD.

10. Annexe : Pistes Évaluées & Moteurs Non Retenus

Au cours de la campagne de benchmarks, d'autres approches techniques ont été implémentées et mesurées. Bien qu'intéressantes, elles n'ont pas été retenues pour l'architecture cible en raison de leurs compromis opérationnels.

A. Identifiants TSID 64-bit (bigint) vs UUID v7

Le TSID (Time-Sorted Identifier) encode un identifiant unique horodaté sur 64 bits (bigint), contre 128 bits pour l'UUID v7.

• Hypothèse : Réduire la taille de la clé primaire de moitié pour doubler la densité des pages d'index B-Tree de 8 Ko et optimiser l'occupation dans les shared_buffers.
• Mesures :
  • En lecture (GET) : Légère hausse de 53 319 req/s (UUID v7) à 53 991 req/s (TSID), soit un gain de +1,3 %.
  • En écriture (SET) : Contention sur la bordure d'index générant un pic de latence P99 à 253,8 ms (contre 173,8 ms pour l'UUID v7).
• Décision : Le gain marginal en lecture ne compense pas la dégradation en écriture. L'UUID v7 (normalisé RFC 9562 et natif depuis PostgreSQL 17) reste le choix le plus équilibré.

B. Tables Partitionnées PostgreSQL (Declarative Partitioning)

Découpage de la table de cache en sous-partitions (par plages de hachage ou temporelles) afin de réduire la profondeur des index B-Tree.

• Hypothèse : Accélérer les recherches et simplifier la purge de données périmées via des opérations DROP TABLE de partitions.
• Mesures : Une fois la mémoire préchauffée, le planificateur résout les index non partitionnés en $O(\log N)$. Aucun gain de débit significatif n'a été mesuré en lecture comme en écriture.
• Décision : Le partitionnement ajoute une complexité de maintenance DDL (gestion dynamique des partitions, surcharge de planification) sans gain de performance sur un jeu de données tenant en RAM.

C. Cache In-Memory Go basique via sync.Map

Utilisation de la structure concurrente sync.Map de la bibliothèque standard Go.

• Hypothèse : Bénéficier d'une map concurrente sans gestion explicite de verrous pour les accès fréquents en lecture.
• Mesures : Excellent débit en lecture, mais absence native de politique d'éviction (LRU/LFU) et de gestion d'expiration (TTL).
• Décision : Le développement d'un moteur d'éviction sur mesure autour de sync.Map introduit des verrous globaux et des goroutines de nettoyage complexes. L'utilisation d'une bibliothèque éprouvée comme Otter v2 (basée sur S3-FIFO) offre de meilleures garanties d'utilisation mémoire.