Hosted Sinks : diffusez les données blockchain directement dans votre base Postgres ou ClickHouse

Amener les données on-chain jusque dans une base de données a toujours été la partie pénible. Vous pouvez écrire la logique de mapping, mais il faut ensuite la faire tourner : provisionner des serveurs, surveiller un processus de sink, gérer les réorganisations de chaîne, faire tourner les identifiants et resynchroniser dès que quelque chose dérive. C'est le travail d'une équipe plateforme entière qui vous sépare d'une table que vous pourriez interroger.

Hosted Sinks supprime ce travail. C'est un service de sink Substreams entièrement géré, disponible sur The Graph Market. Vous indiquez un package Substreams et une base de données, vous cliquez sur Deploy, et StreamingFast exécute le sink pour vous, à l'échelle, de façon sécurisée et sans aucune opération de votre côté. Les données de chaîne fraîches commencent à arriver dans vos tables en quelques minutes, et vous les interrogez avec les outils SQL que vous utilisez déjà.

Cet article explique ce que fait un Hosted Sink, comment les développeurs s'en servent, comment le connecter à des fournisseurs de bases gérées comme Supabase, Neon et ClickHouse Cloud, et comment superviser et administrer un sink une fois qu'il tourne.

Ce que fait concrètement un Hosted Sink

Un package Substreams transforme des données blockchain brutes en sortie structurée. Un sink prend cette sortie et l'écrit quelque part ; ici, dans votre base de données. Normalement, c'est à vous d'exécuter ce processus de sink. Un Hosted Sink l'exécute à votre place.

Concrètement, un hosted sink lit en continu les données de votre package Substreams et les écrit dans votre propre base Postgres ou ClickHouse. Vous fournissez le .spkg (avec un module db_out ou des mappings relationnels) et les informations de connexion à la base. StreamingFast provisionne l'infrastructure, la maintient en fonctionnement sur une infrastructure distribuée et hautement disponible, et alimente la base au fur et à mesure de l'arrivée des nouveaux blocs.

Quelques éléments qui distinguent cette approche d'un pipeline ETL blockchain maison :

• Aucun nouveau runtime sur votre infrastructure. Votre package Substreams transforme le Protobuf directement en tables relationnelles. Il n'y a aucune plomberie blockchain à exploiter ; vous relisez les résultats en SQL classique.
• Conscient des réorganisations, et toujours correct. Substreams suit la chaîne canonique et remonte automatiquement les signaux de fork. Lors d'une réorganisation, le sink applique les bons inserts, updates et upserts : vous ne vous retrouvez jamais avec des données tronquées ou périmées. Aucun nettoyage manuel.
• Curseur géré, donc auto-réparation. Le sink enregistre sa position et reprend exactement au dernier bloc confirmé après toute interruption. Aucune donnée réindexée depuis zéro, aucun trou.
• Postgres ou ClickHouse, à vous de choisir. Postgres pour des données transactionnelles servant une application, ClickHouse pour de l'analytique colonnaire et des tableaux de bord.
• Toutes les chaînes de The Graph Market. Ethereum, Base, Solana, et plus encore.

Comment les développeurs en tirent parti

La valeur apparaît le plus vite lorsque vous avez une requête concrète à exécuter sur des données blockchain en temps réel. Quelques exemples :

Alimenter le backend d'une application. Supposons que vous construisiez un portefeuille ou une application de suivi de portefeuille et que vous ayez besoin des soldes et transferts ERC-20 courants sur Base. Déployez un package Substreams avec un module db_out vers Postgres, nommez le sink base-erc20-transfers, et votre application lit les soldes avec un simple SELECT. Aucun appel RPC, aucun indexeur à maintenir. Comme le sink applique des upserts lors des réorganisations, les soldes vus par vos utilisateurs restent corrects, même à travers les réorganisations de chaîne.

Tableaux de bord analytiques. Si vous suivez le volume d'un DEX, la TVL ou les prix planchers de NFT, pointez le même package vers ClickHouse. Le stockage colonnaire de ClickHouse rend rapides les agrégations sur des millions de lignes : un tableau de bord Grafana ou Metabase qui interroge le volume de swaps quotidien reste réactif à mesure que votre historique grandit.

Alimenter un pipeline de données. Comme la sortie n'est rien d'autre que des tables dans votre propre base, tout ce qui parle SQL en aval (modèles dbt, script Python, outil de BI) fonctionne immédiatement. Vous ne vous intégrez pas à une API propriétaire ; vous interrogez une base que vous possédez déjà.

Le schéma est toujours le même : écrivez un package (ou forkez-en un existant depuis substreams.dev), choisissez votre base, et laissez le sink garder les tables à jour. Vous passez votre temps sur la requête et sur le produit, pas sur le pipeline.

Mise en place : guides pour les bases gérées

Votre base doit être joignable depuis l'infrastructure de StreamingFast (qui tourne depuis us-central1, en Iowa). La documentation contient des guides pas à pas pour les trois fournisseurs gérés les plus courants, pour vous éviter de deviner les paramètres de connexion.

• Supabase : Postgres géré, avec une offre gratuite généreuse. Le détail important : utilisez l'hôte de connexion directe (db.<project-ref>.supabase.co), et non l'hôte du pooler, car PgBouncer interfère avec les requêtes préparées du sink. Mode SSL require ou supérieur.
• Neon : Postgres serverless capable de descendre à zéro. Un sink qui tourne en continu garde l'endpoint éveillé ; sachez simplement que les endpoints de l'offre gratuite se suspendent après une période d'inactivité, donc utilisez une offre payante en production.
• ClickHouse Cloud : ClickHouse entièrement géré. Deux pièges à connaître : le port natif est 9440 (TLS) et non le 9000 standard, il faut donc activer Secure (TLS) ; et vous devrez ouvrir l'IP Access List pour que StreamingFast puisse se connecter.

Pour les trois, le schéma recommandé est identique : créez un utilisateur de base dédié, limité à un seul schéma avec droits d'écriture, et ne confiez au sink que ces identifiants. Les guides fournissent le SQL CREATE USER et GRANT exact pour chaque fournisseur.

La configuration du sink lui-même tient en un court formulaire dans le portail : donnez-lui un nom, fournissez le package (une URL publique ou un identifiant substreams.dev comme ethereum_common@v0.3.3), renseignez la connexion à la base, définissez votre bloc de départ et votre module de sortie (par exemple db_out), puis cliquez sur Deploy. Vous pouvez aussi trouver le package à sinker sur substreams.dev et cliquer sur l'onglet Hosted dans la section Run Package. Le sink passe par l'état Deploying puis, une fois les pods prêts, Deployed, et commence à indexer.

Il suffit de remplir un seul formulaire et de cliquer sur Deploy

Administrer un sink une fois qu'il tourne

Déployer n'est que le premier jour. La page de détail du sink vous donne les contrôles du quotidien pour l'exploiter en production.

Visibilité. Un résumé d'exécution affiche les réplicas prêts par rapport aux réplicas demandés, les instances actives et le nombre de redémarrages (un nombre élevé signale une instabilité). Chaque pod indique son bloc courant par rapport à la tête de chaîne ainsi que sa dérive par rapport à la tête de chaîne, c'est-à-dire le nombre de secondes de retard sur le temps réel ; une valeur proche de zéro signifie que le pod est en direct et à jour. Les états de pod vont de Initiating à Catching up puis Live, et un journal complet des événements de déploiement enregistre chaque changement de cycle de vie, pour auditer ou diagnostiquer.

Modifier sans interruption. Besoin de mettre à jour le package, de changer la configuration d'exécution ou de renouveler les identifiants de base ? Modifiez le sink sur place : le déploiement se met à jour progressivement, le processus redémarre automatiquement et reprend à son dernier curseur.

Arrêter, démarrer, réinitialiser. L'arrêt ramène le déploiement à zéro réplica tout en conservant la configuration ; le démarrage reprend au dernier curseur, donc rien n'est réindexé depuis zéro. Si vous voulez vraiment repartir de zéro, par exemple parce que votre schéma a changé, réinitialisez à partir d'un nouveau bloc de départ pour resynchroniser depuis le début. (La réinitialisation est irréversible et vide le schéma cible : c'est un choix délibéré, pas un accident.)

Supprimer. La suppression retire le processus de sink hébergé et ses pods. Votre base et vos données restent intactes ; seul le sink géré disparaît.

Ce que ça coûte

La facturation fonctionne comme aujourd'hui : vous ne payez que pour les données produites par vos Substreams. Jusqu'à la fin 2026, StreamingFast gère le sink lui-même gratuitement. Ensuite, chaque sink entraînera un coût mensuel négligeable, confirmé avec vous avant tout début de facturation.

En résumé

Hosted Sinks fait disparaître la gestion des identifiants, la mise à l'échelle et les casse-têtes de resynchronisation, et vous rend un simple formulaire et un bouton Deploy. Vous cessez de mobiliser une équipe plateforme pour déplacer des données blockchain vers une base, et vous commencez à interroger ces données avec les outils SQL que vous connaissez déjà.

Vos données. Votre base. L'infrastructure de StreamingFast. En ligne en quelques minutes.

Lisez la documentation et déployez votre premier sink