Retour aux articles
4 min de lecture

Arrête de payer pour des queues et des locks, utilise Postgres

Postgres fait les queues, les locks, et le stockage de documents. T'as pas besoin de six services pour 50 users.

PostgresArchitectureDevEx

Ton SaaS a 50 utilisateurs et tu fais tourner Redis pour le cache, RabbitMQ pour les queues, MongoDB pour les schémas flexibles, et Pinecone pour la recherche vectorielle. Ça fait 400€/mois et quatre trucs de plus à monitorer.

Postgres fait tout ça. Les queues, les locks, le stockage de documents, la recherche full-text, la similarité vectorielle, les données time-series, le pub/sub messaging. Une seule base de données, battle-tested, déjà dans ta stack!

pgvector ajoute les opérations vectorielles pour les embeddings et la recherche par similarité. pg_cron lance des jobs programmés. Les extensions transforment Postgres en ce dont t’as besoin sans ajouter de services!

Postgres comme queue

SKIP LOCKED permet à plusieurs workers de récupérer des jobs sans se bloquer:

SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;

Les workers font tourner ça en boucle. Pas de race conditions, garanties ACID, pas de message broker!

Locks distribués

Les advisory locks coordonnent les tâches entre instances:

SELECT pg_try_advisory_lock(12345);

Retourne true si t’as le lock, false si un autre process le tient. Se libère automatiquement à la déconnexion. Pas besoin de Redis!

Stockage de documents

JSONB stocke des données flexibles et les requête rapidement avec des index GIN:

CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  data JSONB
);
CREATE INDEX ON events USING GIN(data);

-- Requêter des champs nested
SELECT * FROM events WHERE data->>'button_id' = 'signup';

Marche bien pour les feature flags, préférences user, et tracking d’events. Les perfs matchent les bases de documents sous 100GB!

Les perfs sont bonnes

Les queues SKIP LOCKED gèrent des milliers de jobs par seconde. Les advisory locks prennent des microsecondes. JSONB reste rapide sous 100GB.

À 200 requêtes/minute avec 50 users, Postgres gère tout. À 50,000 requêtes/seconde, t’auras besoin de services spécialisés. T’auras aussi les revenus pour les payer!

Recherche vectorielle

pgvector gère les embeddings et la recherche par similarité:

CREATE EXTENSION vector;
CREATE TABLE docs (embedding vector(1536));
CREATE INDEX ON docs USING ivfflat (embedding vector_cosine_ops);

-- Trouver similaires
SELECT * FROM docs ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector LIMIT 5;

Gère 500k embeddings avec des requêtes sous 100ms. Pinecone devient utile à des millions de recherches par seconde!

Recherche full-text

Recherche intégrée avec stemming, ranking, et highlighting:

CREATE TABLE articles (
  search_vector tsvector GENERATED ALWAYS AS
    (to_tsvector('french', title || ' ' || content)) STORED
);
CREATE INDEX ON articles USING GIN(search_vector);

SELECT * FROM articles WHERE search_vector @@ to_tsquery('postgres & performance');

Marche bien pour des millions de documents. Elasticsearch compte à partir de milliards!

Vrais coûts

Avec des services séparés:

  • Postgres (DigitalOcean managé, single node): 15€/mois
  • RabbitMQ (CloudAMQP): 50€/mois
  • Redis (Upstash ou ElastiCache): 25€/mois
  • MongoDB Atlas (M5 partagé): 25€/mois
  • Pinecone (Standard avec minimum): 70€/mois
  • Total: 185€/mois

Avec juste Postgres:

  • Postgres: 15€/mois
  • Total: 15€/mois

Économise 170€/mois et élimine quatre services à monitorer, mettre à jour, et débuguer!

Le vrai coût c’est pas les frais d’hébergement. C’est le temps passé à gérer les backups, gérer les montées de version, débuguer entre services, et écrire du code infra pour chacun!

J’ai vu des boîtes cramer de l’argent pas en infra, mais pour trouver des gens capables de maintenir le bordel qu’ils avaient exigé. Ils embauchaient des prestas à 300€/mois, les enchaînaient les uns après les autres, n’industrialisaient rien du tout. Pendant qu’ils se battaient avec leur archi, la concurrence shippait des features et leur piquait des users!

Quand ajouter des services

RabbitMQ, Redis, Elasticsearch, et Pinecone sont d’excellents outils conçus pour des problèmes spécifiques. Tu les utiliseras un jour!

Mais à 50 users, ta contrainte c’est pas l’infra. C’est le temps et l’argent. Chaque service coûte les deux:

  • Frais mensuels en pré-revenus
  • Setup et monitoring
  • Charge mentale de tracker la santé
  • Debug cross-système

Ajoute des services dédiés quand tu tapes:

  • 10,000+ jobs/seconde de façon constante
  • Routing pub/sub complexe
  • Des dizaines de millions d’embeddings
  • Des milliards de documents à indexer

Quand tu atteins ces chiffres, t’auras les revenus pour migrer correctement. D’ici là, focus sur construire un truc que les gens payent!

Bref

Les services spécialisés existent pour de bonnes raisons. RabbitMQ gère des millions de messages par seconde. Redis sert des hits de cache en microsecondes. Elasticsearch fait de la recherche à échelle massive!

Tu les utiliseras un jour. Juste pas aujourd’hui.

Aujourd’hui, t’as besoin de ship des features et trouver des clients payants. Postgres gère les queues, les locks, la recherche vectorielle, et le stockage de documents assez bien pour t’y amener!

Quand tu le dépasseras, t’auras les revenus pour migrer correctement. T’auras des utilisateurs qui dépendent de toi, ce qui veut dire que tu peux justifier le temps engineering pour splitter les services comme il faut.

Commence simple. Ajoute de la complexité quand tu mesures le besoin, pas quand tu l’imagines!

La réalité est souvent plus nuancée. Moi, la nuance ça m'ennuie. Je préfère la clarté.

Commentaires