pg_lake vs Lakebase : quand « PostgreSQL + Lakehouse » ne veut pas dire la même chose

Snowflake et Databricks proposent chacun une solution qu'ils présentent comme « PostgreSQL intégré à un lakehouse ». Les noms se ressemblent, le positionnement marketing aussi. Pourtant, sous le capot, ces deux approches sont presque opposées. Comprendre cette différence est essentiel avant de choisir l'architecture de votre pipeline de données.

Cet article s'appuie sur l'analyse de Christophe Pettus publiée sur The Build.

Deux philosophies radicalement différentes

pg_lake (Snowflake) : PostgreSQL étendu vers l'extérieur

pg_lake est une extension de PostgreSQL, pas une réécriture. Le moteur reste un binaire Postgres standard et non modifié. Les tables heap classiques continuent d'exister dans des fichiers heap, le MVCC fonctionne exactement comme vous le connaissez, et le WAL (Write-Ahead Log) écrit toujours sur disque local.

Ce que pg_lake ajoute, c'est la capacité de définir des tables Iceberg — stockées sous forme de fichiers Parquet dans un object storage — et de les interroger comme s'il s'agissait de tables natives. PostgreSQL lui-même agit en tant que catalogue Iceberg. Pour les scans analytiques lourds, les requêtes sont déléguées à un processus auxiliaire exécutant DuckDB, spécialisé dans le traitement colonnaire.

L'architecture ressemble à ceci :

[ Client SQL ]
      |
[ PostgreSQL (binaire standard) ]
      |              \
[ Heap tables ]   [ Tables Iceberg → Parquet / Object Storage ]
                        |
                   [ DuckDB (sidecar analytique) ]

Ce qui est préservé : la compatibilité transactionnelle complète sur les tables heap, la sémantique MVCC native, l'écosystème d'extensions Postgres.

Ce qu'il faut garder en tête : les tables Iceberg ne bénéficient pas du même niveau de garanties transactionnelles ACID que les tables heap. Ce sont deux types de stockage cohabitants, avec des comportements différents.

Lakebase (Databricks) : PostgreSQL avec le moteur de stockage remplacé

Lakebase adopte une stratégie inverse. La couche de calcul est bien un binaire Postgres — vous utilisez le même SQL, les mêmes drivers, les mêmes outils. Mais le moteur de stockage a été entièrement remplacé par celui de Neon, la startup acquise par Databricks en 2025.

Neon dissocie le compute du storage : les données ne vivent plus dans des fichiers heap locaux, mais dans un système de stockage distribué basé sur des pages, conçu pour le cloud. Cela permet une scalabilité quasi-instantanée, la mise en veille des instances, et une facturation à l'usage.

L'architecture ressemble à ceci :

[ Client SQL ]
      |
[ PostgreSQL (surface de programmation) ]
      |
[ Moteur de stockage Neon (distribué, cloud-native) ]
      |
[ Object Storage / Pages distribuées ]

Ce qui est préservé : l'interface SQL PostgreSQL, la compatibilité des drivers et des outils clients.

Ce qu'il faut garder en tête : vous n'êtes plus sur un PostgreSQL standard. Le comportement en termes de latence, de durabilité et de garanties transactionnelles dépend de l'implémentation Neon, qui peut diverger sur des cas limites de MVCC ou de crash recovery.

L'impact concret sur vos données et vos requêtes

Cohérence des données

Avec pg_lake, la cohérence transactionnelle est forte sur les tables heap classiques. Mais dès que vous mélangez des écritures sur des tables heap et des tables Iceberg dans une même transaction, vous sortez du périmètre ACID standard. Les garanties dépendent de l'implémentation de la couche Iceberg et de la façon dont les commits sont coordonnés.

Avec Lakebase, le modèle transactionnel est celui de Neon. Neon est conçu pour être compatible PostgreSQL, mais la séparation compute/storage introduit des subtilités : les snapshots, la gestion des pages en mémoire, et le comportement en cas de failover ne sont pas identiques à ceux d'un PostgreSQL classique sur disque local.

Règle pratique : si la cohérence transactionnelle stricte est votre priorité absolue (transactions financières, données critiques), pg_lake sur des tables heap est plus proche du comportement PostgreSQL que vous maîtrisez déjà.

Performances de requêtage

pg_lake excelle pour les requêtes analytiques sur de grands volumes grâce à la délégation vers DuckDB. Pour les requêtes OLTP classiques, vous restez sur PostgreSQL standard avec ses performances habituelles. L'optimiseur doit cependant décider quand déléguer à DuckDB et quand exécuter localement — une complexité supplémentaire à surveiller.

Lakebase est optimisé pour les workloads cloud-native où l'élasticité prime : scale-up rapide, mise en veille des instances inutilisées, multi-tenant. La latence sur les premières requêtes après une période d'inactivité peut être plus élevée (cold start), ce qui est inhérent à l'architecture Neon.

Quel choix pour quel contexte ?

Choisissez pg_lake si vous avez des workloads mixtes OLTP/analytique, que vous tenez à la compatibilité comportementale de PostgreSQL, et que vos données lakehouse sont principalement en lecture avec des écritures ponctuelles.

Choisissez Lakebase si vous construisez une application cloud-native nécessitant une forte élasticité, que vous êtes déjà dans l'écosystème Databricks, et que la surface SQL PostgreSQL suffit sans dépendance au moteur interne.

Conclusion

Le terme « PostgreSQL » est devenu un label marketing autant qu'une description technique. pg_lake et Lakebase sont deux réponses valides à des problèmes différents — mais les confondre peut conduire à des choix d'architecture aux conséquences importantes sur la cohérence de vos données et les performances de vos requêtes.

Avant d'adopter l'une ou l'autre solution, posez-vous les bonnes questions : quelle est votre tolérance aux divergences comportementales par rapport à PostgreSQL standard ? Quelles sont vos garanties transactionnelles minimales ? Votre workload est-il principalement OLTP, analytique, ou mixte ?

Ces décisions d'architecture ont des impacts durables. Chez MulerTech, nous accompagnons les équipes techniques dans ces choix d'infrastructure data, notamment pour les projets Symfony nécessitant une intégration avec des systèmes de stockage distribués.