Ne synchronisez jamais la planète entière dans votre base applicative

81 455 423 lieux embarquent dans la version 2026-09-23.1 d'Overture Maps, et Postgres peut tous les contenir. Les insertions se terminent. L'index spatial se construit. La séduction opère. Le piège se paie après coup : une base choisie avant que quiconque connaisse le profil des requêtes répond aux questions pour lesquelles elle a été construite, et refuse discrètement le reste.

Notre affirmation est plus étroite qu'une synthèse. La destination d'un extrait Overture a une seule entrée réelle : la forme de la requête qui va la frapper. Le goût de l'équipe n'en fait pas partie. Ne pointez jamais une base applicative vers la version complète. Découpez d'abord un extrait régional avec DuckDB, puis déposez-le dans le moteur que la charge de travail implique. Ce qui suit est un seul chemin de décision avec trois destinations, et chaque destination gagne sa charge de travail, sans partage.

L'extrait passe d'abord, quelle que soit sa destination

Une règle vaut sous chaque toit de ce billet. Entre la version et toute base depuis laquelle vous servez se trouve un extrait, borné à la région où vous opérez réellement, découpé avec DuckDB dans le GeoParquet sur place. Nous avons détaillé ces mécaniques dans le billet précédent sur l'interrogation d'Overture avec DuckDB. Ce qui compte pour le stockage : un prédicat sur la colonne struct bbox élimine des fichiers Parquet et des lignes entières sans toucher une seule géométrie. C'est ainsi qu'une boîte englobante sur le lac Tahoe renvoie 28 166 lieux en 2,77 secondes et 106 242 segments de transport en 18,0 secondes. La mesure vient de DuckDB 1.5.6, le 11 octobre 2026, contre la version 2026-09-23.1.

Cet extrait est aussi la seule unité de transfert saine de cet écosystème, et GeoParquet en est la raison. Overture publie du GeoParquet, l'extrait reste du GeoParquet, et le moteur qui le charge ensuite consomme la même forme de fichier, quel que soit ce moteur. L'identifiant de version voyage dans le job qui a produit le fichier, si bien que chaque magasin en aval sait quelle version du monde il décrit.

La version sceptique de cette section se lit « laisse l'index s'en charger », et face à un thème complet l'index aide une requête, pas le cycle mensuel de rafraîchissement. Le thème places seul compte 81 455 423 lignes à réimporter à chaque version, et le rafraîchissement est la partie qui se répète. Bordez d'abord la région et le rafraîchissement devient une requête régionale de deux secondes suivie d'un chargement borné, autrement dit une après-midi tranquille au lieu d'un projet de migration.

DuckDB gagne les questions qui arrivent par lots

Les charges de travail analytiques quittent à peine DuckDB. Toute question posée contre une version épinglée, qu'il s'agisse d'un audit qualité ou d'une jointure d'enrichissement de vos propres données vers le thème places, s'exécute là où les données se trouvent déjà. Le moteur est colonnaire et lit le GeoParquet sans traduction. L'extension spatiale porte les fonctions de géométrie, et puisqu'il n'y a aucun serveur à lancer, l'extraction et l'analyse peuvent être le même processus, le même jour.

Appuyons la démonstration. Une question comme « quels magasins de meubles de cette zone de livraison n'ont aucun site web » a la forme d'un lot. Personne n'attend debout devant la réponse, donc elle tourne dans DuckDB contre la version 2026-09-23.1, et le résultat repart sous forme de fichier.

La limite est la concurrence. DuckDB est un moteur analytique unique, pas un serveur transactionnel, et il ne prendra pas les écritures concurrentes d'une application. Ce n'est pas grave, parce que le moteur de lots termine son travail quand la réponse atterrit dans un fichier, idéalement un fichier GeoParquet, prêt pour le magasin qui fait le service.

PostGIS gagne les questions qui interrompent une application

Un utilisateur dépose une épingle et l'application lui doit une zone de livraison avant que le compteur ne devienne insupportable. C'est une question de point-dans-polygone aléatoire, posée une fois par interaction, sous charge concurrente, avec la réponse jointe au reste de vos tables métier. Postgres avec PostGIS gagne cette charge de travail. Un index GiST répond aux recherches spatiales aléatoires, les transactions gardent les rédacteurs concurrents honnêtes, et la jointure entre géographie et votre schéma est du SQL ordinaire :

SELECT zone.name
FROM delivery_zones zone
WHERE ST_Contains(zone.geometry, ST_SetSRID(ST_MakePoint(-120.4, 39.1), 4326));

Avec un index GiST sur delivery_zones.geometry, cette requête est la forme de presque toutes les questions de couche de service qu'un extrait Overture affrontera du côté relationnel. L'accès aléatoire est toute l'histoire ici. L'extrait chargé dans PostGIS existe pour que la carte réponde par utilisateur au lieu de par lot.

Le coût est le chargement, et il est réel. Le thème places seul compte 81 455 423 lignes dans la version 2026-09-23.1, et la même boîte englobante de Tahoe a compté 228 935 bâtiments en 37,1 secondes de requête DuckDB. Le thème addresses est plus lourd encore : 474 millions d'éléments que la documentation d'Overture marque toujours alpha. Importer un thème complet fait de chaque version mensuelle un événement de maintenance avec votre astreinte dessus. La solution de contournement est déjà en place si vous avez suivi la première section : chargez l'extrait plutôt que le thème, et épinglez la version dont l'extrait est issu.

MongoDB gagne quand le pipeline parle déjà documents

Certaines chaînes parlent déjà documents, et pour elles l'interface Python officielle d'Overture, maintenue dans l'organisation GitHub OvertureMaps, écrit un téléchargement directement dans une MongoDB en marche :

overturemaps download --mongodb

Un enregistrement places survit à ce trajet comme un document, ce qu'il a toujours été. Les tableaux de websites et addresses restent des tableaux, et brand et taxonomy gardent leur imbrication. La géométrie du point arrive en GeoJSON, indexée par un index 2dsphere, si bien qu'une question de proximité devient le travail natif du magasin au lieu d'une jointure étrangère.

Ce chemin gagne quand l'application qui consomme l'extrait est déjà un magasin documentaire. Un service de catalogue qui stocke ses enregistrements en documents reçoit l'extrait dans le style de collection de ses propres données, et répond à ses questions de proximité depuis le même moteur. Introduire un système relationnel pour le privilège de stocker des points en lignes, c'est un second système à sauvegarder, et la couche d'adaptation entre documents et tables est du vrai travail qui n'achète rien ici.

La limite honnête est la profondeur. Le vocabulaire géospatial de MongoDB, 2dsphere, couvre les types de géométrie GeoJSON jusqu'aux polygones, et il s'arrête avant le géotraitement. Il n'y a pas de st_buffer, et rien dans la base ne construit de nouvelle géométrie à partir de la géométrie existante. La solution de contournement garde la chaîne honnête : calculez le tampon dans DuckDB pendant l'extraction, et déposez le polygone fini pour que MongoDB l'indexe et le serve.

Chaque moteur a une limite dure, et chaque limite a une solution de contournement

La limite de PostgreSQL, c'est l'import lui-même. Ce que coûte un chargement de thème complet, c'est surtout le rythme, plus que les octets : constructions d'index et cycles de vacuum, un tour par version mensuelle, aux dates qu'Overture choisit. L'issue est la circonscription : le thème reste en Parquet, et la base applicative ne voit jamais une version entière.

La limite de MongoDB est le vocabulaire, et la conséquence suit directement. Ce que 2dsphere donne à la voie documentaire, il le borne aussi. Le magasin répond avec la géométrie que vous avez chargée, jamais avec la géométrie qu'il calcule, donc chaque polygone dérivé doit déjà se trouver dans l'extrait. L'issue est une étape DuckDB plus ample, qui ne touche pas le magasin du tout.

La limite de DuckDB est le rôle de service qu'il ne peut pas tenir. Les lecteurs peuvent partager un fichier sans difficulté, mais une application écrit toute la journée, et les rédacteurs n'ont qu'un processus à la fois. L'issue est qu'il n'a jamais à tenir ce rôle : ses réponses repartent en fichiers, et les fichiers sont l'entrée que tout autre moteur ici comprend.

Le chemin de décision, en un tableau et trois questions

Posez d'abord une question : quelqu'un attend-il la réponse ? Si non, la question a la forme d'un lot et DuckDB la garde, contre la version épinglée, avec GeoParquet en sortie. Si oui, posez-en une seconde : le système autour des données parle-t-il déjà documents ou relations ? Les documents aiguillent l'extrait vers MongoDB, les relations vers PostgreSQL. Dans les deux cas, le moteur que vous faites déjà tourner est la destination la moins chère, parce que l'extrait est la partie qui se déplace.

La requête qui arrive	Où l'extrait se dépose	La raison qui tranche
Agrégats par version et enrichissement d'enregistrements	DuckDB sur GeoParquet	Colonnaire et sur place, sans serveur à maintenir en vie
La question point-dans-polygone d'un utilisateur, sous charge	PostgreSQL avec PostGIS	Accès aléatoire indexé, avec garanties relationnelles
Un service documentaire qui consomme des enregistrements places	MongoDB	L'interface y écrit directement, et les lignes sont déjà des documents

Le goût de l'équipe choisit la base qu'une entreprise possède déjà. Le profil des requêtes devrait choisir celle que vous ajoutez, et GeoParquet porte l'extrait entre les deux de toute façon.

L'extrait est l'architecture. La base en dessous reste négociable, et la version mensuelle en est le rappel.

AngoraTek construit des chaînes Overture épinglées par version, de l'extrait DuckDB jusqu'au moteur qui sert votre charge de travail. [Montrez-nous la requête qui doit être rapide](/fr/#contact) et nous parcourrons le chemin de décision avec vous.