🦆 OLTP / OLAP géospatial
Quack redessine la frontière du serveur SIG

---

🔄 DuckDB renverse sa propre doctrine

Le 12 mai 2026, l'équipe DuckDB a publié Quack, son protocole client-serveur officiel. Pour mesurer l'événement, il faut se rappeler que DuckDB s'est construit sur le refus exact de ce modèle : une base in-process, embarquée dans votre script Python ou votre notebook, sans serveur, sans DBA, sans port à ouvrir.

Cette doctrine reste valide pour l'analytique interactive. Mais elle se heurtait à un mur dès que plusieurs processus devaient lire et écrire la même base. L'écosystème avait répondu par une accumulation de contournements — RPC maison, Arrow Flight, MotherDuck, pg_duckdb — dont la prolifération a fini par convaincre l'équipe : le besoin était légitime.

La trajectoire devient limpide quand on la met bout à bout :

• 2023 — extension spatiale (GEOS embarqué, fonctions ST_* inspirées de PostGIS)
• 2024-2025 — GeoParquet natif, lecture directe sur S3, extension H3
• 2026 — protocole client-serveur officiel

💡 Insight #1 — Ce qui se joue vraiment
La question n'est pas "DuckDB va-t-il tuer PostGIS ?". C'est la séparation OLTP / OLAP — tranchée il y a vingt ans dans le monde des bases de données — qui arrive enfin en géomatique. Le transactionnel d'un côté, l'analytique de l'autre, et un protocole pour servir le second.

---

⚙️ Quack sous le capot

Transport : HTTP, assumé

Pas de protocole binaire propriétaire sur TCP : Quack roule sur HTTP. Choix pragmatique et revendiqué — "HTTP has become a de-facto protocol layer on top of TCP". Conséquences concrètes :

• traverse les pare-feux et s'intègre derrière un reverse proxy (nginx + Let's Encrypt pour l'exposition Internet)
• profite de l'infrastructure de sécurité existante (WAF, détection d'intrusion)
• fonctionne avec DuckDB-Wasm dans le navigateur : un dashboard web peut interroger directement un serveur Quack, sans backend intermédiaire

Sérialisation : format maison, pas de traduction

Les données circulent avec un type MIME dédié, application/duckdb, qui réutilise les primitives de sérialisation internes de DuckDB — les mêmes qui font tourner le Write-Ahead Log depuis des années. Pas de conversion vers un format d'échange neutre, donc pas de coût de traduction. C'est un choix assumé contre l'interopérabilité d'Arrow, au profit de la performance et de la liberté d'évolution.

Un seul aller-retour réseau par requête

C'est l'argument architectural central. Arrow Flight SQL impose au minimum deux round-trips par requête (CommandStatementQuery puis DoGet). Quack traite une requête complète en un seul échange. Sur des petites requêtes fréquentes — le quotidien d'un dashboard — la latence réseau domine le temps de réponse : diviser les allers-retours par deux est décisif.

Sécurité par défaut

• token aléatoire généré au démarrage du serveur
• binding localhost uniquement par défaut
• SSL automatiquement obligatoire dès que la connexion n'est pas locale
• authentification extensible par callbacks (LDAP, fichier, logique métier)
• port par défaut 9494 — clin d'œil à 1994, année de Netscape Navigator

---

🛠️ Exemple complet : un serveur analytique géospatial

Scénario : une VM modeste héberge vos référentiels convertis en tables DuckDB (un GeoPackage de parcelles, les bâtiments Overture en GeoParquet). Les agents, scripts et notebooks s'y connectent à distance.

Étape 1 — Côté serveur

-- Extensions spatiale + serveur
INSTALL spatial; LOAD spatial;

-- Démarrer le serveur Quack (binding réseau + token)
CALL quack_serve(
    'quack:0.0.0.0',
    token = 'super_secret'
);

-- Charger les référentiels une fois, côté serveur
CREATE TABLE parcelles AS
  FROM ST_Read('parcelles_saclay.gpkg');

CREATE TABLE batiments AS
  FROM 'overture/buildings/*.parquet';  -- GeoParquet lu tel quel

Étape 2 — Côté client (CLI DuckDB, n'importe quelle machine)

-- Déclarer le secret d'authentification
CREATE SECRET (
    TYPE quack,
    TOKEN 'super_secret'
);

-- Attacher la base distante comme une base locale
ATTACH 'quack:srv-geo.mondomaine.local' AS remote;

-- Interroger les tables distantes
FROM remote.parcelles LIMIT 10;

Étape 3 — Client Python (notebook, script, tâche planifiée)

import duckdb

con = duckdb.connect()
con.sql("CREATE SECRET (TYPE quack, TOKEN 'super_secret')")
con.sql("ATTACH 'quack:srv-geo.mondomaine.local' AS remote")

df = con.sql("""
    SELECT b.id, ST_Area(b.geometry) AS surface
    FROM remote.batiments b
    JOIN remote.parcelles p ON ST_Intersects(b.geometry, p.geom)
    WHERE p.commune = 'Palaiseau'
""").df()

Étape 4 — Pousser le calcul côté serveur

La fonction query() envoie du SQL verbatim exécuté côté serveur. Le calcul lourd se fait près des données, seul le résultat traverse le réseau :

-- Agrégation exécutée sur le serveur, résultat seul transféré
FROM remote.query('
    SELECT commune, COUNT(*) AS nb, SUM(ST_Area(geometry)) AS surface_totale
    FROM batiments GROUP BY commune
');

💡 Insight #2 — Le pattern qui change la donne
Serveur Quack + GeoParquet + clients Wasm = un dashboard cartographique sans backend, interrogeant en SQL spatial une instance centrale, pour le coût d'une petite VM. Là où la réponse classique était "il faut monter un GeoServer et une base PostGIS".

---

📊 Les benchmarks officiels

Mesures publiées dans l'annonce DuckDB (instances EC2 m8g.2xlarge, latence réseau 0,28 ms).

Transfert en masse — 60 millions de lignes TPC-H

Écritures transactionnelles — petites transactions concurrentes

Deux lectures honnêtes de ces chiffres :

• Sur le bulk transfer — le cas analytique typique : rapatrier un gros résultat — l'écart est massif. C'est exactement le terrain où le protocole PostgreSQL, conçu ligne à ligne, souffre depuis toujours.
• Sur les petites écritures, Quack tient tête à Postgres jusqu'à 8 threads, puis plafonne. La limite vient de DuckDB lui-même (insertions concurrentes), pas du protocole. Pour du transactionnel multi-utilisateurs soutenu, Postgres garde l'avantage structurel.

---

🧭 OLTP ou OLAP : où va chaque workload ?

Posez ces questions pour chaque flux de données géospatiales de votre SI. Le pattern général : PostGIS garde la transaction, la pile GeoParquet + DuckDB prend l'analyse.

⚠️ Les limites à connaître avant de migrer

• C'est une preview. La version production est annoncée avec DuckDB v2.0 à l'automne 2026.
• Pas d'index spatiaux comparables au GiST : le colonnaire excelle en scan, pas en requête ponctuelle. Contournement : tri par courbe de Hilbert + pruning min/max — mais ça se prépare.
• Un seul écrivain, plafond constaté vers 8 threads en insertion concurrente.
• Protocole non standard : seuls des clients DuckDB se connectent à un serveur Quack aujourd'hui.
• Extension spatiale jeune : couverture ST_* incomplète face à 20 ans de PostGIS.
• Roadmap à suivre : read replicas, protocole de réplication, intégration DuckLake (serveur DuckDB comme catalogue distant).

📜 Les 3 règles d'or à imprimer

🔗 Pour aller plus loin

• Annonce officielle : "Quack: The DuckDB Client-Server Protocol" — duckdb.org/2026/05/12/quack-remote-protocol
• Intégration Postgres : "PostGIS meets DuckDB" — Crunchy Data Blog, crunchydata.com/blog/postgis-meets-duckdb-crunchy-bridge-for-analytics-goes-spatial
• Le débat communautaire : "DuckDB is probably the most important geospatial software of the last decade" — Hacker News, news.ycombinator.com/item?id=43881468
• Extension spatiale : documentation DuckDB Spatial — duckdb.org/docs/extensions/spatial