Les sinks Substreams sont désormais intégrés : Uniswap V4 indexé en moins de 8 minutes

Nous avons intégré substreams-sink-sql à la CLI Substreams, tout en améliorant considérablement sa vitesse et ses performances. Vous lancez désormais directement substreams sink postgres ou substreams sink clickhouse, sans binaire séparé à installer et sans choix à faire entre run et from-proto. Passez un package et le mode est détecté automatiquement.

Ce changement va bien au-delà du simple rangement. Le nouveau sink ajoute un spool sur disque, reporte les contraintes Postgres jusqu'à l'arrivée en tête de chaîne, et décode le protobuf avec un unmarshaller bien plus rapide. Dans un benchmark Uniswap V4 mené par BuildersDAO, de The Graph, un backfill complet d'Uniswap V4 sur Ethereum est passé de 23 heures avec un subgraph à seulement 7 minutes 36 secondes avec Substreams, grâce à un abonnement Pro Plan. Soit 182x plus rapide !

Le benchmark

BuildersDAO voulait une comparaison à armes égales entre les subgraphs et Substreams pour l'indexation d'Uniswap V4. Mêmes événements, même base Postgres, mêmes plages de blocs : de 21 688 328 à 23 535 547 sur Ethereum (environ 1,8 M de blocs) et de 25 350 987 à 36 712 209 sur Base (environ 11,4 M de blocs). Ils ont retraité chaque plage avec un subgraph, puis avec Substreams à cache froid et avec différents nombres de workers, en utilisant Substreams v1.22.0 pour les dernières exécutions.

Réseau	Subgraph	Substreams, 75 workers	Gain
Ethereum	23 h 00 min	7 min 36 s	182x
Base	94 h 19 min	2 h 06 min	45x

Environnement du benchmark : Ubuntu 24.04, PostgreSQL 16.14, disque de 1,8 To, package d'événements Uniswap V4, endpoints StreamingFast pour Ethereum et Base mainnet.

Plus de workers, plus de vitesse

Substreams parallélise le traitement de l'historique, et vous contrôlez jusqu'où avec un seul en-tête, X-Substreams-Parallel-Workers. Voici la courbe de montée en charge complète des exécutions en v1.22.0 :

Workers	Réseau Ethereum (durée)	vs subgraph	Réseau Base (durée)	vs subgraph
1	8 h 12 min	2,8x	28 h 41 min	3,3x
5	1 h 37 min	14x	26 h 51 min	3,5x
15	36 min	38x	9 h 10 min	10x
75	7 min 36 s	182x	2 h 06 min	45x
300	7 min 30 s*	184x	56 min 38 s	100x

Benchmark BuildersDAO · Substreams v1.22.0 · cache froid.

*Les gains d'Ethereum plafonnent autour de 75 workers, alors que Base a bien plus de données à traiter et continue donc de progresser de 75 à 300. Plus le backfill est long, plus les workers supplémentaires paient.

Échelle logarithmique sur l'axe du temps ; les lignes pointillées indiquent la référence subgraph de chaque chaîne.

Avec 300 workers, le débit a atteint 4 103 blocs/s sur Ethereum et 3 343 blocs/s sur Base, de bout en bout jusque dans Postgres.

Ce qui a changé dans le sink

Les premières exécutions de BuildersDAO nous ont indiqué les goulots d'étranglement. Trois changements expliquent l'essentiel de l'amélioration depuis :

• Un spool sur disque. Les données sont téléchargées dans un spool local (8 GiB par défaut) et validées dans la base de manière asynchrone, si bien qu'une base lente ne bloque plus le flux. Cela seul apporte jusqu'à 10x sur le débit du sink Postgres. Veillez à ce que l'hôte du sink dispose de suffisamment d'espace disque pour le spool.
• Contraintes appliquées en tête de chaîne. Les contraintes Postgres ne sont plus créées au début d'un backfill. Elles sont appliquées lorsque vous atteignez les blocs en direct, ou à la demande avec substreams sink postgres constraints apply, et elles peuvent être construites en parallèle. C'est la même astuce que de charger Postgres sans index puis de les construire ensuite.
• Un unmarshaller protobuf plus rapide. Nous avons remplacé dynamicpb par hyperpb, soit un décodage 18x plus rapide et une seule arène mémoire par bloc au lieu de milliers d'allocations.

BuildersDAO a aussi partagé un conseil pratique : ingérez d'abord les tables brutes jusqu'à la tête de chaîne, puis faites une pause et construisez vos vues matérialisées. Les vues matérialisées lourdes exécutées pendant le backfill étaient le goulot d'étranglement, et les désactiver a donné un gain immédiat.

Migration

Les bases de données existantes continuent de fonctionner. Les tables de curseur et les schémas sont inchangés : vous pouvez donc mettre un sink en pause, mettre à jour la CLI et reprendre depuis votre curseur sans retraitement. Les principales différences :

Avant	Maintenant
substreams-sink-sql run $DSN manifest.yaml 100:200	substreams sink postgres manifest.yaml -s 100 -t 200 --dsn $DSN
substreams-sink-sql from-proto ...	Détecté automatiquement d'après le type du module de sortie
substreams-sink-sql setup $DSN manifest.yaml	substreams sink postgres setup manifest.yaml --dsn $DSN
DSN en argument positionnel, ou PG_DSN / CLICKHOUSE_DSN	Option --dsn ou SUBSTREAMS_SINK_DSN
--metrics-listen-addr	--prometheus-addr

Le guide de migration couvre chaque option et chaque changement Docker. Le dépôt substreams-sink-sql est en cours de dépréciation, et les nouveaux dialectes SQL se trouvent désormais dans le dépôt substreams, sous sink/sql.

Le skill Substreams est lui aussi mis à jour

Le skill Substreams pour les agents de code IA enseigne désormais les commandes intégrées substreams sink postgres et substreams sink clickhouse, afin que des agents comme Claude Code génèrent la syntaxe actuelle plutôt que celle du binaire déprécié.

Pour installer le skill, suivez la présentation des skills, ou récupérez les neuf depuis le dépôt GitHub pour devenir un expert Substreams.

À vous de jouer

Mettez à jour la CLI Substreams (v1.22.0 ou ultérieure), pointez substreams sink postgres ou substreams sink clickhouse vers votre package, et définissez votre nombre de workers.

Un grand merci à l'équipe BuildersDAO d'avoir mené ce benchmark et de nous avoir poussés à examiner de plus près ce qui ralentissait la synchronisation. Leurs retours ont façonné plusieurs de ces changements.

Vous avez vos propres résultats ? Venez nous les partager sur Discord.