Un warehouse en Europe,
au prix fixe d’une machine.
Faire tourner dbt, Airflow, ClickHouse, DuckDB ou Spark sur des VPS européens facturés au mois — pas de frais à la requête, pas de coût au To scanné, pas de crédits. Garder les events bruts sur un stockage objet compatible S3, facturé au Go stocké par mois, et entraîner les modèles la nuit sur un GPU réservé. Les données restent en UE, sur une stack qui t’appartient.
Anatomie d’un pipeline data moderne
Ta facture DWH croît plus vite que ta donnée.
Tu ingères des événements, fais tourner des ETL la nuit, entraînes des modèles chaque semaine et livres des dashboards. Chaque DWH cloud facture séparément le scan, le stockage, l’egress — chaque ligne anodine, le total surprenant. Sur VPS + stockage objet, le warehouse est une machine facturée au mois quel que soit le nombre de requêtes ; le lake se paie au Go stocké, plus les requêtes et le trafic selon sa grille.
Chaque hop tourne sur VMCloud — Kafka écrit le Parquet dans le bucket, ClickHouse charge les partitions utiles sur son VPS, Metabase requête ClickHouse. Les requêtes tapent les disques du warehouse : pas de frais à la requête ; les lectures du bucket comptent en requêtes et en trafic selon la grille du stockage objet.
Orchestrer l’ETL comme une équipe data senior
Tu lis tes DAGs tous les matins.
Une équipe data a besoin de trois primitives : un scheduler, un framework de transformation, un runner de tests. Airflow / Dagster + dbt + dbt-tests couvrent tout. Tout tourne sur un seul VPS de milieu de gamme pour les petites équipes ; on passe à 3 nœuds quand on dépasse quelques centaines de modèles dbt. Même outillage à chaque étape.
Sources → lake brut → modèles staging + tests → mart → BI. Airflow lance le DAG chaque nuit, retry les tâches en échec, post sur Slack au rouge.
Un vrai modèle dbt + DAG Airflow
-- models/marts/mart_revenue.sql{{ config(materialized='incremental', unique_key='order_id') }}selecto.order_id,o.customer_id,date_trunc('day', o.created_at) as order_date,o.amount_eur,c.countryfrom {{ ref('stg_orders') }} ojoin {{ ref('stg_customers') }} c using (customer_id)where o.status = 'paid'{% if is_incremental() %}and o.created_at > (select max(order_date) from {{ this }}){% endif %}-- schema.ymlversion: 2models:- name: mart_revenuecolumns:- name: order_idtests: [unique, not_null]- name: amount_eurtests:- not_null- dbt_utils.expression_is_true:expression: ">= 0"
- ✓Airflow / Dagster sur un VPS de milieu de gamme
- ✓Workers Celery / Kubernetes pour les étapes lourdes
- ✓dbt 1.8+ avec manifest stocké sur S3
- ✓Événements OpenLineage postés à un service de métadonnées
- ✓Métriques de durée et d’échec remontées par chaque worker
- ✓Slack + email sur fail DAG ou freshness manquée
Un stockage qui scale comme S3, requête comme une DB
Tu scannes plus de data que tu n’en stockes.
Un warehouse 10 To sur Snowflake coûte ~230 $ par mois juste pour exister, puis BigQuery / Snowflake facturent le compute ou le To scanné à chaque requête. Sur VMCloud, un volume bloc STORAGE-NVME de 10 To coûte 1 500,00 € HT/mois et l’engine (ClickHouse, DuckDB) le scanne autant que tu veux — pas de frais au To scanné. L’historique brut reste sur le stockage objet, payé au Go stocké.
Cumul fin d’année : ~96 To. Sur OBJ-STANDARD à 0,02 € HT/Go·mois, le stockage du dernier mois revient à 1 910,06 € HT — requêtes et trafic selon la grille. Des règles de cycle de vie déplacent les partitions froides vers une classe moins chère.
Latence requête par taille de warehouse
| lignes | moteur | VPS | p50 | p95 | note |
|---|---|---|---|---|---|
| 10 M | DuckDB | 4 vCPU · 8 GB | 0.18 s | 0.6 s | idéal analyste seul |
| 100 M | DuckDB | 6 vCPU · 16 GB | 0.9 s | 2.4 s | petit warehouse |
| 1 B | ClickHouse | 32 vCPU · 128 GB | 1.4 s | 4.1 s | DWH intermédiaire |
| 10 B | ClickHouse · 3 nodes | 3 × 32 vCPU · 128 GB | 3.2 s | 9.5 s | grosse équipe |
Ordres de grandeur pour un jeu de données bien partitionné — ton schéma et tes requêtes décident. Un seul VPS à grande mémoire avec ClickHouse tient un milliard de lignes confortablement en analytique ; au-delà, on shard sur plusieurs nœuds. La grille tarifaire VPS donne l’offre de chaque taille.
L’entraînement ML de nuit, sur un GPU réservé
Tu réentraînes par semaine, pas en continu.
La plupart des équipes data ont besoin de 4 à 8 heures de GPU par semaine — un modèle de churn, un recommender, un détecteur d’anomalies. Les plateformes SaaS ML (Vertex AI, SageMaker) facturent à la seconde de GPU et ajoutent stockage, egress et frais de notebook. Une instance GPU au mois fait tourner le job nocturne et reste à toi le reste de la semaine pour l’ad-hoc et l’inférence ; pour quelques runs ponctuels, une plateforme à la seconde — ou la facturation à l’heure sur devis — peut revenir moins cher.
La carte reste réservée à ton instance le reste de la journée : notebooks, inférence, relances.
Pas de scan par To, pas de surcoût notebook
Même stack, taille d’équipe différente.
Analyste seul avec un lake de 1 To : un VPS de milieu de gamme. Équipe data qui passe à 10 To avec ETL quotidien : un VPS à grande mémoire. Équipe ML : on ajoute un GPU pour l’entraînement nocturne. Les tableaux ci-dessous chiffrent chaque profil depuis la grille tarifaire et le comparent au SaaS managé le plus proche — le prix mensuel fixe se rentabilise quand le volume de requêtes grandit.
cost = vps_month + gpu_month + lake_gb × price_gb_month
Trois composants prévisibles. Pas de "credit", pas de "DBU", pas de "slot", pas de frais à la requête sur le warehouse. La formule correspond aux box que l’équipe utilise vraiment : un VPS warehouse qui tourne 24/7 et un GPU gardé pour l’entraînement, tous deux facturés au mois (à l’heure sur devis), et un lake qui grandit chaque mois, payé au Go stocké — requêtes et trafic selon la grille du stockage objet.
| profil | capacité | composition | par mois |
|---|---|---|---|
| Analyste seul | ~1 To de lake · DuckDB + Metabase | VPS-BUSINESS · 1 To OBJ-STANDARD | 169,19 € |
| Équipe data | ~10 To de lake · ClickHouse + Airflow | VPS-TITANIUM · 10 To OBJ-STANDARD | 1 691,93 € |
| Entraînement ML | ~5 To de lake · batch GPU + warehouse | VPS-BUSINESS · GPU-PRO · 5 To OBJ-STANDARD | 1 079,83 € |
Lake : Go stockés par mois uniquement — requêtes et trafic selon la grille du stockage objet. VPS et GPU facturés au mois, la facturation à l’heure se fait sur devis.
| Snowflake · X-Small warehouse | 40 h/mois de compute | + stockage 23 $/To/mois | $ 240 |
| BigQuery · on-demand | 40 To/mois scannés | + stockage 20 $/To | $ 227 |
| Databricks · Standard SQL | small warehouse | + DBU + stockage | $ 350 |
| AWS Athena | 50 To/mois scannés | + S3 + Glue catalog | $ 250 |
| Redshift · ra3.xlplus | cluster 24/7 | + S3 spectrum | $ 1 100 |
Prix pour une charge "petite équipe data" (warehouse 10 To, 40 h compute/mois, dashboards quotidiens). Les vraies factures ajoutent stockage, compute, scan, DBU, egress. Compter +30–50 %.
| profil | VMCloud | par mois HT | SaaS le plus proche | par mois | lecture |
|---|---|---|---|---|---|
| Analyste · 1 To · dashboards ad-hoc | Analyste seul | 169,19 € | BigQuery · light usage · 5 To scannés + stockage | 80 $ | SaaS moins cher |
| Équipe · 10 To · ETL quotidien | Équipe data | 1 691,93 € | Snowflake · X-Small + storage · 40 h compute + 10 To | 420 $ | SaaS moins cher |
| Scaleup · 100 To scannés/mois | Équipe data | 1 691,93 € | Databricks · medium SQL · compute + DBU + stockage | 1 800 $ | équivalent |
| Équipe ML · 5 To + train GPU nuit | Entraînement ML | 1 079,83 € | BigQuery + Vertex AI · scan data + heures GPU | 950 $ | équivalent |
Lecture : à faible usage, un DWH managé facturé à la requête ou au crédit coûte souvent moins cher — le tableau le montre. Le prix d’un bundle VMCloud ne bouge pas avec le nombre de requêtes : plus tu scannes, plus la facture fixe se rentabilise, et la donnée reste en UE sur une stack qui t’appartient. Les requêtes et le trafic du lake s’ajoutent, selon la grille du stockage objet.
De vraies questions d’équipes data
D’analysts, data engineers et ML leads qui hésitent entre DWH SaaS et self-hosted.
ClickHouse, DuckDB ou Postgres — quel moteur ?›
DuckDB pour analyste seul et notebook — tourne in-process, requête Parquet S3 directement. Postgres pour les workloads OLTP-leaning avec peu de lignes. ClickHouse pour OLAP à l’échelle du milliard : columnar, distribué, sub-seconde sur agrégations. Les trois tournent sur un VPS : choisis la taille dans la grille tarifaire selon ton volume de données et ta mémoire.
Iceberg, Delta ou Parquet pur ?›
Parquet pur sur S3 si ton pipeline est append-only et versionné dans Git. Iceberg si tu veux ACID, évolution de schéma, time travel — et requête multi-moteur. Delta Lake si tu es Databricks-heavy. Les trois sont open-source et tournent sur les mêmes buckets de stockage objet compatible S3.
Puis-je utiliser dbt-cloud ou je self-host ?›
dbt-core est open-source, tu self-host le compilateur et le lances sur VPS — c’est ce qu’on décrit ici. dbt-cloud est la couche SaaS (UI, scheduler, lineage UI) facturée par dev. Tu peux faire l’un ou l’autre ; dbt-cloud sur un warehouse VMCloud marche très bien. La plupart self-hostent à partir de 10+ devs.
Comment migrer depuis Snowflake ?›
Trois étapes : dump tes tables en Parquet sur S3 (Snowflake a un COPY INTO), monter un VPS ClickHouse qui lit le Parquet directement, pointer dbt sur le nouveau warehouse. La plupart prennent 2 à 4 semaines ; le SQL dbt demande quelques ajustements (macros Snowflake → ClickHouse). Les frais d’egress Snowflake sont la mauvaise surprise — compter environ 0,09 $/Go sortant. Notre équipe peut t’accompagner dans la migration sur devis (CGV §10.5).
RGPD + auditabilité ?›
Stockage et compute sont hébergés dans des centres de données OVHcloud en UE, et le DPA couvre les obligations RGPD du sous-traitant. Les buckets offrent règles de cycle de vie, versioning, object lock (rétention et conservation légale) et journaux d’accès — les briques de ta propre piste d’audit. Les colonnes PII peuvent être masquées au niveau warehouse (RBAC ClickHouse) et la suppression sur demande est un simple DELETE si tu partitionnes par user_id.
Requête multi-moteur sans copies ?›
Oui — stocker Parquet/Iceberg une seule fois sur S3, le requêter depuis DuckDB (notebook analyste), ClickHouse (warehouse), Spark (ETL lourd) et dataloaders PyTorch (entraînement ML) en même temps. Le lake est la source de vérité ; les moteurs sont des readers stateless. Pas de duplication, pas de logique de sync — chaque lecture compte en requêtes et en trafic selon la grille du stockage objet : garde les partitions chaudes sur les disques du warehouse.
Prêt à posséder ta data ?
Stockage objet + VPS warehouse + GPU réservé — le même Parquet lu par chaque moteur, un warehouse facturé au mois plutôt qu’à la requête, données en UE.