pgEdge fusionne OLTP et OLAP dans ColdFront, une base Postgres pensée pour l’analytique temps réel

pgEdge annonce ColdFront, une offre qui vise à réunir dans un même système les usages OLTP et OLAP, longtemps séparés dans les architectures de données d’entreprise. L’éditeur met en avant une approche centrée sur PostgreSQL, avec l’ambition de réduire les duplications de données, les délais entre production et analyse, et la complexité opérationnelle liée aux pipelines ETL et aux entrepôts dédiés.

pgEdge présente ColdFront pour unifier OLTP et OLAP

Historiquement, les organisations ont isolé les charges transactionnelles et analytiques pour éviter que les requêtes lourdes ne dégradent les applications métiers. Les bases OLTP servent les opérations courantes, paiements, commandes, inventaires, tandis que les plateformes OLAP alimentent la BI, les tableaux de bord et la modélisation. Cette séparation a produit un schéma devenu classique, une base transactionnelle, un bus d’événements ou des extractions, puis un entrepôt ou un lakehouse, avec des données recopiées et transformées.

Avec ColdFront, pgEdge affirme vouloir casser cette dichotomie en rapprochant l’analytique du transactionnel. L’idée opérationnelle, telle qu’elle est généralement recherchée sur ce type de produits, consiste à limiter les copies, diminuer la latence, et permettre des analyses au plus près du temps réel, sans attendre un chargement nocturne ou des micro-batchs. Dans de nombreux secteurs, la valeur se joue sur des fenêtres de quelques minutes, détection de fraude, ajustement de prix, suivi logistique, monitoring d’usage, ou pilotage de campagnes.

Le positionnement revendiqué s’inscrit dans une tendance plus large, les entreprises veulent des décisions plus rapides, mais se heurtent à la fragmentation des outils. Entre la base de production, les systèmes de cache, les moteurs analytiques et les couches de gouvernance, chaque ajout apporte des coûts, licences, intégration, compétences, et risques d’incohérence. Sur le terrain, un indicateur calculé dans l’entrepôt peut diverger de celui affiché dans l’application, simplement parce que les données n’ont pas la même fraîcheur.

Dans ce contexte, l’argument central d’une fusion OLTP et OLAP tient à la simplification. Moins de mouvements de données signifie aussi moins de points de défaillance, moins de jobs de transformation à superviser, et un meilleur contrôle des accès. La promesse reste conditionnée à des choix techniques précis, isolation des charges, gestion de la concurrence, formats de stockage, et capacité à absorber des requêtes analytiques sans pénaliser les transactions.

PostgreSQL au cur de ColdFront, avec une logique de base distribuée

PostgreSQL est devenu une brique standard dans de nombreuses entreprises, pour ses fonctionnalités, son écosystème et la disponibilité des compétences. En s’appuyant sur cet ADN, pgEdge cherche à capitaliser sur la compatibilité applicative, connecteurs, ORM, drivers, pratiques SQL, et outils d’observabilité. Pour une DSI, conserver une surface SQL familière peut réduire le risque de migration, surtout quand des applications critiques reposent déjà sur Postgres.

La question clé est celle de l’architecture. Les besoins modernes, haute disponibilité multi-région, résilience, proximité utilisateur et conformité, poussent vers des modèles distribués. Un système qui vise à servir à la fois du transactionnel et de l’analytique doit gérer la réplication, la cohérence, les conflits potentiels, et la répartition de charge. Dans les déploiements multi-sites, le coût réseau et la latence deviennent des paramètres structurants, notamment pour les écritures.

Dans les faits, la distribution est souvent recherchée pour deux raisons, réduire la latence côté utilisateurs finaux et renforcer la continuité d’activité. Une entreprise de e-commerce opérant en Europe et en Amérique du Nord peut vouloir rapprocher les lectures des clients, tout en conservant une vue consolidée pour l’analyse. Unifier OLTP et OLAP dans ce cadre implique de maîtriser les impacts, par exemple, une requête analytique globale peut solliciter plusieurs nuds, tandis que les transactions exigent une réponse rapide et prévisible.

Le choix d’une base Postgres distribuée vise aussi à éviter la multiplication de moteurs spécialisés. Dans un environnement où un entrepôt analytique, un moteur de recherche, une base clé-valeur et un streaming coexistent, les équipes passent du temps à synchroniser les définitions, les schémas, et les règles de qualité. L’approche de pgEdge mise sur une consolidation autour de PostgreSQL, tout en cherchant à répondre à des usages analytiques qui, traditionnellement, poussaient vers des solutions colonnaires ou des moteurs MPP.

Réduire l’ETL et la duplication des données, un gain opérationnel attendu

Dans un schéma classique, les données quittent la base transactionnelle via des extractions, CDC, files de messages ou connecteurs, puis sont transformées avant d’atterrir dans un entrepôt. À chaque étape, il faut gérer des erreurs, des schémas qui évoluent, des retards, et des coûts de stockage supplémentaires. L’ambition d’un système unifié est de limiter ces transferts, avec un impact direct sur la charge d’exploitation.

Les coûts sont rarement uniquement techniques. L’ETL mobilise des équipes data engineering, impose des fenêtres de maintenance, et produit des dépendances entre domaines. Quand un champ change dans une table de production, il faut mettre à jour les pipelines, les modèles, puis les tableaux de bord. Les incidents typiques sont connus, données manquantes, doublons, retards d’actualisation, ou divergences de calcul. En réduisant la duplication, ColdFront cherche à diminuer ces frictions et à rapprocher la source de vérité des usages analytiques.

Le bénéfice attendu est particulièrement visible sur les cas d’usage temps réel. Dans la lutte contre la fraude, une décision se prend souvent sur la base d’événements récents, tentatives de paiement, variations de comportement, signaux d’appareil, géolocalisation approximative. Si l’analyse arrive avec 30 minutes de retard, la valeur diminue fortement. Un modèle OLTP/OLAP unifié vise à rendre ces signaux exploitables immédiatement, sans attendre un chargement.

Il existe aussi un enjeu de gouvernance. Dupliquer les données multiplie les surfaces d’accès, donc les risques. Les mêmes informations personnelles peuvent se retrouver dans plusieurs systèmes, avec des politiques de rétention différentes. Un système unifié, s’il est correctement conçu, peut faciliter l’application de règles cohérentes, chiffrement, contrôle d’accès, audit, et suppression. Le gain n’est pas automatique, il dépend des mécanismes fournis et de leur adoption, mais l’objectif est clairement identifié par les entreprises soumises à des contraintes réglementaires.

Les limites techniques, isolation des charges et performances sous requêtes mixtes

Fusionner OLTP et OLAP soulève une contrainte majeure, les charges ne se comportent pas de la même manière. Les transactions sont courtes, nombreuses, sensibles à la latence, tandis que l’analytique peut lancer des scans, des agrégations et des jointures coûteuses. Sans garde-fous, l’analytique peut monopoliser CPU, mémoire ou I/O, et ralentir les applications métiers. Les promesses d’unification s’évaluent donc sur la capacité à isoler les charges, à prioriser, et à maintenir une qualité de service.

Sur le plan des données, l’analytique réclame souvent des optimisations spécifiques, index adaptés, partitions, matérialisations, et parfois des formats de stockage différents. Un système unifié doit arbitrer entre flexibilité et spécialisation. Si l’on reste trop proche d’un schéma transactionnel, les requêtes BI peuvent devenir coûteuses. Si l’on optimise trop pour l’analytique, on peut pénaliser les écritures. L’équilibre dépend des volumes, du modèle de données, et des objectifs de fraîcheur.

La distribution ajoute une autre couche de complexité. Les requêtes analytiques globales peuvent exiger des échanges entre nuds, ce qui introduit des coûts réseau. Les transactions, elles, tolèrent mal les allers-retours. Les entreprises devront examiner des critères concrets, latence inter-région, stratégie de réplication, tolérance aux partitions réseau, et comportement en cas de bascule. Dans un contexte multi-cloud ou multi-région, ces paramètres peuvent faire la différence entre une architecture robuste et un système difficile à opérer.

Enfin, la comparaison avec les entrepôts analytiques modernes reste inévitable. Les plateformes colonnaires et MPP sont optimisées depuis des années pour les scans massifs et les agrégations. Un système Postgres unifié devra démontrer des performances suffisantes sur des cas analytiques exigeants, tout en maintenant les garanties transactionnelles. Pour les entreprises, l’adoption passera souvent par des pilotes ciblés, tableaux de bord opérationnels, reporting proche du temps réel, ou analyses sur des sous-ensembles de données, avant de remplacer des briques analytiques lourdes.