Une PME ouest-africaine qui démarre une boutique en ligne, une plateforme SaaS facturée en FCFA ou une stack analytique pour son comité de direction se pose tôt ou tard la même question : sur quel moteur de données s’appuyer pour ne pas changer de pied dans dix-huit mois ? Trois noms reviennent presque toujours dans l’arbitrage : PostgreSQL, le moteur OLTP polyvalent et open source, ClickHouse, le moteur OLAP columnar self-hostable conçu pour l’analytique massive, et BigQuery, le datawarehouse serverless de Google Cloud. Aucun n’est universellement supérieur. Ce comparatif 2026 dégage une matrice de décision claire, adaptée au contexte d’une équipe data ouest-africaine, avec des coûts chiffrés en FCFA et des seuils de bascule explicites.
L’objectif n’est pas de classer des outils dans l’absolu mais de répondre à trois profils-types : la PME OLTP de 50 à 500 commandes par jour, la startup data-driven qui ingère 10 millions à 1 milliard d’événements par mois, et l’entreprise multi-pays qui veut donner de l’analytique ad-hoc à plusieurs équipes. Pour chaque profil, le bon moteur n’est pas celui qui gagne sur le benchmark, c’est celui qui aligne volumétrie, latence requise, coût récurrent et opérabilité humaine sur trois à cinq ans.
📍 Guide principal : ClickHouse 2026 : analytics columnar haute performance — pour la vue d’ensemble du moteur OLAP référent côté self-hosted. Ce comparatif éclaire le choix entre les trois moteurs ; le guide principal détaille le fonctionnement interne de ClickHouse seul.
Pourquoi le choix du moteur structure trois ans de roadmap
Choisir un moteur de données n’est pas un détail technique. C’est un engagement à long terme sur les compétences que l’équipe va recruter et former, sur le coût récurrent qui apparaîtra chaque mois sur la facture cloud ou la facture d’hébergement, et sur la dette d’exploitation qu’on accumulera si on se trompe. Migrer plus tard de PostgreSQL vers ClickHouse coûte généralement entre 20 et 80 jours-homme selon la complexité de la stack analytique existante. Migrer de BigQuery vers du self-hosted demande de réécrire les requêtes, refondre les pipelines d’ingestion, recruter un profil data engineer là où un dev fullstack avec un peu de SQL suffisait. Ces déplacements ne se rattrapent pas en optimisant deux requêtes : ils impliquent des décisions structurelles d’architecture.
Le bon réflexe en 2026 est de raisonner en TCO sur trois à cinq ans, qui inclut quatre composantes : le coût direct (licences, abonnements cloud, hébergement VPS), le coût opérationnel (jours-homme par an pour la maintenance, monitoring, sauvegardes, montées de version), le coût d’opportunité (lenteur de développement si le moteur n’est pas adapté au pattern de requêtes), et le coût de sortie (effort de migration le jour où le contexte change). Les trois moteurs étudiés ici ne se positionnent pas du tout au même endroit sur ces quatre axes, et c’est précisément ce qui motive un choix éclairé plutôt qu’un choix par défaut.
PostgreSQL : OLTP polyvalent qui couvre 80 % des besoins PME
PostgreSQL est en 2026 sur sa branche stable 18 (GA le 25 septembre 2025), avec la version 17 (sortie le 26 septembre 2024) toujours maintenue jusqu’en novembre 2029. C’est un moteur relationnel transactionnel ACID, généraliste, capable de tenir des charges OLTP exigeantes (commandes e-commerce, comptabilité, gestion de contenu) jusqu’à plusieurs dizaines de milliers de transactions par seconde sur un seul serveur correctement dimensionné. Son écosystème d’extensions (PostGIS pour le spatial, pg_partman pour le partitionnement, TimescaleDB pour les séries temporelles, pgvector pour les embeddings) en fait un moteur véritablement polyvalent qui couvre la plupart des cas d’usage des PME.
Les forces de PostgreSQL pour une PME ouest-africaine sont claires. Le moteur est gratuit, open source sous licence permissive (PostgreSQL Licence proche de BSD), et tourne sur un VPS Hetzner CX32 à environ 6,80 EUR par mois (autour de 4 500 FCFA). La communauté francophone est solide, les compétences se trouvent à Dakar, Abidjan ou Bamako, et la documentation officielle postgresql.org/docs est exhaustive. Pour une PME qui traite 50 à 500 commandes par jour avec un site marchand, un module CRM et de la facturation, PostgreSQL est le choix par défaut sans débat.
Les limites apparaissent quand la volumétrie analytique devient sérieuse. Une table de logs applicatifs qui atteint 100 millions de lignes commence à peser sur les requêtes GROUP BY et JOIN larges. Le moteur stocke les données en lignes (row-based), ce qui pénalise les requêtes analytiques qui n’utilisent que 3 colonnes sur 50. Les solutions existent (partitioning, index colonnes via BRIN, agrégats matérialisés) et sont détaillées dans le guide PostgreSQL en surcharge, mais elles complexifient la stack. Au-delà du téraoctet de hot data, on bascule mécaniquement sur un moteur columnar.
Cas d’usage idéal : application transactionnelle PME, mix lecture-écriture équilibré, volumétrie sous le téraoctet, équipe d’un à trois développeurs qui veulent un seul moteur pour tout faire. Pour les séries temporelles IoT spécifiquement, regarder TimescaleDB sur PostgreSQL qui étend le moteur pour ce pattern précis sans changer de produit.
ClickHouse : OLAP self-hostable haute performance
ClickHouse est un moteur columnar open source écrit en C++ par les équipes initialement issues de Yandex, désormais opéré commercialement par ClickHouse Inc. depuis 2021. Sa version actuelle en mai 2026 tourne sur la branche 25.x, avec des LTS publiées tous les six mois. Le moteur est conçu pour une seule chose : exécuter des requêtes analytiques sur de très gros volumes très rapidement, en lisant uniquement les colonnes nécessaires depuis un stockage compressé. Sur un benchmark TPC-H modeste, ClickHouse surclasse PostgreSQL d’un facteur 10 à 100 sur les requêtes SELECT larges avec agrégations.
Les forces côté self-hosted sont remarquables. Le coût d’infrastructure pour un cluster trois noeuds avec haute disponibilité tient en 22 EUR par mois (≈14 500 FCFA) sur Hetzner — soit dix fois moins qu’une instance BigQuery équivalente sur les charges intensives. Les moteurs de table MergeTree et leurs variantes répliquées (ReplicatedMergeTree, ReplicatedSummingMergeTree, ReplicatedAggregatingMergeTree) couvrent les patterns OLAP classiques. Pour un déploiement en cluster avec haute disponibilité, le tutoriel cluster ClickHouse + Keeper détaille le pas-à-pas complet.
Les limites tiennent à l’opérabilité. ClickHouse demande une équipe data familière avec les concepts columnar, les sharding policies, les politiques de TTL, les compromis sur les materialized views. Le moteur n’est pas adapté aux écritures unitaires fréquentes — il faut batcher les inserts par groupes d’au moins 10 000 lignes pour ne pas déclencher des erreurs Too many parts. Les transactions ACID ne sont pas la priorité : ClickHouse n’a pas de UPDATE ou DELETE conventionnel sur les MergeTree, on utilise des ALTER TABLE ... DELETE qui sont asynchrones et coûteux.
Cas d’usage idéal : startup data-driven qui ingère 10 millions à 1 milliard d’événements par mois (logs applicatifs, événements e-commerce, télémétrie IoT), équipe avec au moins un profil data ou DevOps senior pour gérer le cluster, dashboards opérationnels qui exigent des temps de réponse sous la seconde sur des datasets volumineux. Pour un démarrage à plus petite échelle, l’aperçu de la stack data 2026 présente d’autres alternatives plus légères comme DuckDB.
BigQuery : datawarehouse cloud serverless
BigQuery est le datawarehouse managé de Google Cloud Platform, lancé en 2010, devenu serverless avec un modèle de tarification à la requête en 2014, puis élargi à un modèle capacity-based (slots) en 2023. Le service stocke les données dans un format columnar propriétaire (Capacitor) répliqué sur l’infrastructure Google, avec un moteur de requêtes massivement parallèle (Dremel) capable de scanner plusieurs téraoctets en quelques secondes. Aucune instance à provisionner, aucun cluster à gérer, aucune montée de version à programmer.
Les forces sont uniques sur le marché. Pas d’opérabilité — l’équipe écrit du SQL standard et oublie l’infrastructure. Le free tier offre 10 Go de stockage et 1 To de requêtes par mois, ce qui couvre largement les premières expérimentations d’une équipe data. La tarification à la requête est transparente : 6,25 USD par téraoctet scanné en mode on-demand sur la région standard, sans coût d’attente quand personne ne requête. L’intégration native avec Google Workspace, Looker Studio, Sheets et l’écosystème GA4 est imbattable pour les organisations déjà sur GCP.
Les limites tiennent au pricing imprévisible et à la latence réseau. Sans contrôle, une requête mal écrite qui scanne 5 To coûte plus de 30 USD en quelques secondes. Les équipes ouest-africaines font face à une latence de 80 à 150 ms vers les régions Google Cloud les plus proches (Belgique, Frankfurt, Londres), ce qui pénalise les pipelines d’ingestion en streaming et les dashboards interactifs. Le coût peut exploser quand la volumétrie passe à plusieurs téraoctets de hot data interrogés quotidiennement par 10 utilisateurs internes.
Cas d’usage idéal : entreprise multi-pays avec analytics ad-hoc partagée entre équipes (marketing, finance, opérations), équipe technique légère qui ne veut pas gérer d’infrastructure data, charge analytique très variable (pics importants suivis de longues périodes calmes) où le serverless paie. Combiné à dbt et DuckDB pour le développement local, BigQuery offre un workflow professionnel avec versionnement, tests et déploiement.
Matrice de décision sur huit critères clés
Le tableau ci-dessous synthétise les arbitrages structurants. Aucun critère ne domine seul ; l’addition des huit dessine le bon choix selon votre contexte. Les notes vont de 1 (faible) à 5 (excellent) sur chaque axe.
| Critère | PostgreSQL | ClickHouse | BigQuery |
|---|---|---|---|
| OLTP transactionnel | 5 | 1 | 1 |
| OLAP haute volumétrie | 3 | 5 | 5 |
| Coût infra prévisible | 5 | 5 | 2 |
| Opérabilité (équipe légère) | 5 | 3 | 5 |
| Latence dashboards | 4 | 5 | 3 |
| Écosystème extensions | 5 | 3 | 4 |
| Dépendance fournisseur | 1 (faible) | 1 (faible) | 5 (forte) |
| Recrutement compétences OA | 5 | 2 | 3 |
La lecture rapide donne trois patterns clairs. PostgreSQL maximise polyvalence, coût prévisible et compétences disponibles. ClickHouse maximise performance OLAP et coût infra, au prix d’une équipe data qualifiée. BigQuery maximise opérabilité et puissance brute, au prix de la dépendance Google et d’un coût qui peut déraper.
Coûts comparés en FCFA sur trois scénarios concrets
Les chiffres ci-dessous reflètent une estimation 2026 hors taxes locales, basée sur les tarifs publics Hetzner Cloud et Google Cloud. Le taux EUR/FCFA est verrouillé à 1 EUR = 655,957 FCFA (BCEAO). Le taux USD/FCFA flotte autour de 600 FCFA en mai 2026 — utilisé ici à 600 pour la simplicité.
| Scénario | PostgreSQL self-hosted | ClickHouse cluster 3 noeuds | BigQuery on-demand |
|---|---|---|---|
| PME OLTP (10 Go data, 50 commandes/jour) | ≈ 4 500 FCFA/mois (Hetzner CX32) | 14 500 FCFA/mois (sur-dimensionné) | ≈ 0 FCFA/mois (free tier) |
| Startup analytique (1 To hot, 100 utilisateurs analytics) | ≈ 25 000 FCFA/mois (Hetzner CCX23 dédié) | ≈ 14 500 FCFA/mois (cluster optimal) | ≈ 90 000 à 250 000 FCFA/mois (variable) |
| Multi-pays ad-hoc (10 To hot, 50 dashboards quotidiens) | Non viable | ≈ 70 000 FCFA/mois (cluster sharded) | ≈ 200 000 à 500 000 FCFA/mois |
Sur le scénario PME, BigQuery écrase mathématiquement le concurrent self-hosted via son free tier, mais ne couvre pas les besoins OLTP transactionnels du site marchand — il faut alors PostgreSQL en complément. Sur le scénario startup analytique, ClickHouse est imbattable en coût infra, à condition de pouvoir gérer le cluster. Sur le scénario multi-pays ad-hoc, BigQuery devient l’option pragmatique malgré le coût élevé : payer 200 000 FCFA par mois pour ne pas recruter un data engineer à 800 000 FCFA mensuels reste un bon arbitrage.
Pièges fréquents par moteur
| Moteur | Piège classique | Conséquence | Parade |
|---|---|---|---|
| PostgreSQL | Autovacuum désactivé sur les grosses tables | Bloat, lenteur progressive, espace disque saturé | Tuning autovacuum_* + monitoring pg_stat_user_tables |
| PostgreSQL | Index manquants sur les colonnes filtrées | Sequential scans coûteux | EXPLAIN ANALYZE systématique avant déploiement |
| ClickHouse | Inserts unitaires fréquents | Erreur Too many parts |
Batch ≥ 10 000 lignes par INSERT |
| ClickHouse | ORDER BY mal choisi à la création |
Requêtes lentes irréversibles sans recréation de table | Identifier la dimension de filtre principale avant CREATE |
| BigQuery | Requêtes SELECT * sur grosses tables |
Facturation explosive (chaque colonne scannée payée) | SELECT explicite + partitioning + clustering |
| BigQuery | Tables sans partitioning sur date | Scan complet à chaque requête | PARTITION BY DATE(timestamp_col) dès le DDL |
Adaptation au contexte ouest-africain
Trois facteurs locaux pèsent dans la décision. Le premier est la latence vers les datacenters cloud. Hetzner Falkenstein, Helsinki et Nuremberg offrent une latence de 50 à 80 ms vers Dakar, Abidjan ou Bamako, ce qui reste acceptable pour des dashboards opérationnels. Google Cloud Belgique ou Frankfurt tournent autour de 80 à 150 ms — c’est sensible pour un utilisateur final mais transparent pour des batchs nocturnes. Pour réduire la latence sur du critique temps réel, les datacenters africains émergents (Africa Data Centres, Liquid Intelligent Technologies via VIPNET en Côte d’Ivoire, Raxio à Abidjan ouvert depuis 2024) deviennent une option, au prix d’un coût supérieur et d’une offre IaaS plus limitée.
Le deuxième facteur est l’équipe. Recruter un dev fullstack qui connaît PostgreSQL prend une à deux semaines à Dakar ou Abidjan. Recruter un data engineer ClickHouse qualifié peut prendre trois à six mois et coûte entre 600 000 et 1 200 000 FCFA mensuels selon le profil. BigQuery se forme sur le tas avec un dev SQL solide, sans recrutement spécialisé. Cette réalité économique pèse plus que les benchmarks de performance dans une PME qui démarre.
Le troisième facteur est la conformité OHADA et la souveraineté des données. Pour des données qui contiennent des informations personnelles régies par les lois ouest-africaines (Sénégal loi 2008-12, CDP Côte d’Ivoire, équivalents UEMOA), héberger sur du self-hosted dans un datacenter régional simplifie les audits et les déclarations. BigQuery sur région européenne ne pose pas de problème légal automatique, mais la traçabilité du flux de données et les contrats de sous-traitance demandent une vigilance juridique renforcée.
Recommandation finale par profil
La synthèse opérationnelle tient en quatre lignes. Si vous démarrez une PME OLTP avec moins de 500 commandes par jour : PostgreSQL en self-hosted ou managé. Si vous montez une startup data-driven avec une équipe data dédiée et un budget infra serré : ClickHouse en cluster trois noeuds. Si vous outillez une entreprise multi-pays sans équipe data interne : BigQuery, en commençant par le free tier puis en provisionnant des slots dédiés quand le coût on-demand dépasse 300 USD par mois. Si votre cas d’usage croise plusieurs profils : utilisez PostgreSQL pour l’OLTP transactionnel et ClickHouse ou BigQuery pour la couche analytique, avec un pipeline de réplication ou ETL en aval.
Le pire choix est de prendre une décision par habitude ou par effet de mode. Choisir BigQuery parce que c’est tendance alors que vous avez 200 commandes par jour vous coûte une dépendance inutile à Google. Choisir ClickHouse parce que c’est rapide alors que vous n’avez pas d’équipe data finit en cluster non maintenu après six mois. Choisir PostgreSQL parce que c’est gratuit alors que votre charge analytique passera 10 To dans deux ans vous prépare une migration douloureuse. Le bon moteur est celui dont vous comprenez les limites avant de l’adopter, pas celui qui sonne le mieux à un comité de pilotage.
Mots-clés associés : PostgreSQL 17, ClickHouse 25, BigQuery on-demand, datawarehouse PME, OLTP OLAP, MergeTree columnar, slots BigQuery, OHADA souveraineté données, Hetzner Cloud, FCFA TCO data.