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.
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é.