Une data lake en Europe,
sans facture au téraoctet.
Faire tourner dbt, Airflow, ClickHouse, DuckDB ou Spark sur VPS européen, stocker les events bruts sur object store S3-compatible à 0,10 €/Go/mois, et burst l’entraînement ML la nuit sur un vrai GPU — pas de coût par requête, pas de coût par To scanné, pas de piège egress. Tout le pipeline coûte moins qu’un seul warehouse Snowflake.
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 + object store, la formule se réduit à « tu paies la box que tu gardes alive ». Prévisible et ~3× moins cher à l’échelle.
Chaque hop tourne sur le même réseau VMCloud — Kafka écrit sur S3, ClickHouse lit S3, Metabase requête ClickHouse. Pas d’egress entre eux.
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-PERFORMANCE 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 VPS-PERFORMANCE
- ✓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
- ✓Exporters Prometheus sur 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 € juste pour exister, puis BigQuery / Snowflake facturent par To scanné à chaque requête. Sur VMCloud, 10 To sur STORAGE-NVME coûte 1 500 €/mois et tu le scannes autant que tu veux — l’engine (ClickHouse, DuckDB) lit sur le même réseau sans surcoût.
Cumul fin d’année : ~96 To. Sur STORAGE-NVME à 0,10 €/Go/mois, facture du dernier mois = 9550 €. L’équivalent Snowflake (Iceberg compressé + frais de scan) est typiquement 3–4× supérieur.
Latence requête par taille de warehouse
| lignes | moteur | VPS | p50 | p95 | note |
|---|---|---|---|---|---|
| 10 M | DuckDB | VPS-PERFORMANCE | 0.18 s | 0.6 s | idéal analyst seul |
| 100 M | DuckDB | VPS-BUSINESS | 0.9 s | 2.4 s | small warehouse |
| 1 B | ClickHouse | VPS-TITANIUM | 1.4 s | 4.1 s | DWH mid-size |
| 10 B | ClickHouse · 3 nodes | 3× VPS-TITANIUM | 3.2 s | 9.5 s | grosse équipe |
Un seul VPS-TITANIUM (128 Go RAM, 32 vCPU) avec ClickHouse tient 1 G de lignes confortablement en analytique. Au-delà, le sharding sur 3 nœuds scale linéairement.
Burst ML la nuit sur un vrai GPU
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. Un job nocturne sur GPU-PRO coûte ce que coûtent quelques heures SageMaker — et le GPU reste à toi le reste de la semaine pour de l’ad-hoc.
Pas de scan par To, pas de surcoût notebook
Même VPS, taille d’équipe différente.
Analyst seul avec warehouse 1 To : un VPS-BUSINESS + 1 To SSD = 249 €/mois. Équipe data qui passe à 10 To + ETL quotidien : VPS-TITANIUM + 10 To NVMe = ~3 000 €/mois. Équipe ML avec entraînement GPU nocturne : +830 € GPU-PRO. Compare à Snowflake ou Databricks à même taille de data — généralement 2 à 4× plus.
cost = compute_vps + storage_gb + (gpu_hours × rate)
Trois composants prévisibles. Pas de "credit", pas de "DBU", pas de "slot", pas de frais à la requête. La formule correspond à la box que l’équipe utilise vraiment : un VPS warehouse qui tourne 24/7, un volume de stockage qui grandit chaque mois, et un GPU qu’on allume pour l’entraînement.
| profil | capacité | composition | €/mo |
|---|---|---|---|
| Analyst seul | ~1 To warehouse · dbt + Metabase | VPS-BUSINESS · 1 TB STORAGE-SSD | € 249.19 |
| Équipe data | ~10 To warehouse · ClickHouse + Airflow | VPS-TITANIUM · 10 TB STORAGE-NVME | € 2991.93 |
| Entraînement ML | ~5 To · batch GPU + warehouse | VPS-BUSINESS · GPU-PRO · 5 TB STORAGE-NVME | € 1729.83 |
| Snowflake · X-Small warehouse | 40 h/mo compute | + stockage 23 $/To/mois | $ 240 |
| BigQuery · on-demand | 40 To/mois scannés | + stockage 20 $/To | $ 200 |
| 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 | €/mo | SaaS le plus proche | $/mo | lecture |
|---|---|---|---|---|---|
| Analyst · 1 To · dashboards ad-hoc | Analyst seul | €249 | BigQuery · light usage · 5 To scannés + stockage | $80 | SaaS gagne |
| Équipe · 10 To · ETL quotidien | Équipe data | €2 992 | Snowflake · X-Small + storage · 40 h compute + 10 To | $420 | SaaS gagne |
| Scaleup · 100 To scannés/mois | Équipe data | €2 992 | Databricks · medium SQL · compute + DBU + stockage | $1 800 | SaaS gagne |
| Équipe ML · 5 To + train GPU nuit | Entraînement ML | €1 730 | BigQuery + Vertex AI · scan data + heures GPU | $950 | SaaS gagne |
Lecture : un analyst seul à 1 To passe sur BigQuery free tier. L’équation bascule vite — toute équipe avec ETL quotidien à 10 To+ gagne sur VMCloud, et l’écart se creuse à l’échelle parce que le SaaS facture le scan, pas le stockage.
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 analyst 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 VPS-BUSINESS et au-dessus.
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 STORAGE VMCloud.
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 0,09 $/Go sortant.
RGPD + auditabilité ?›
Tous les stockages et compute en régions UE. Les buckets supportent rétention par préfixe, immutabilité et access logs — requis pour audit type SOX. 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 analyst), 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.
Prêt à posséder ta data ?
Object store + VPS warehouse + GPU à la demande — même Parquet lu par chaque moteur, pas de scan au To, pas de piège egress, données en UE.