Skip to main content
AMP-powered subgraphs are a new kind of subgraphs with SQL data sources that query and index data from AMP servers. They are significantly more efficient than standard subgraphs, reducing indexing time from days and weeks to minutes and hours in most cases.
This feature is available starting from spec version 1.5.0.

Prerequisites

To enable AMP-powered subgraphs, set the following environment variables:

Required

Must be set to a valid AMP Flight gRPC service address. Without this, AMP-powered subgraphs are disabled.

Optional (If Authentication Required)

Contains a valid authentication token for the AMP Flight gRPC service.

Subgraph Manifest Structure

AMP-powered subgraphs use a different manifest structure than standard subgraphs.

Minimum Spec Version

The minimum spec version for AMP-powered subgraphs is 1.5.0.

Data Source Overview

Data Source Configuration

kind (Required)

Every AMP data source must have kind: amp. AMP-powered subgraphs must contain only AMP data sources.
Mixing AMP and non-AMP data sources in the same subgraph is not supported.

name (Required)

A non-empty string containing only numbers, letters, hyphens, or underscores. Used for observability and identifying progress and errors.

network (Required)

Valid network name used to validate that SQL queries produce results for the expected network.
Currently, SQL queries must produce results for a single network to maintain compatibility with non-AMP subgraphs.

Source Configuration

The source section describes SQL query behavior.

source.dataset (Required)

Dataset name that SQL queries can access. Validates that queries only use the expected dataset.

source.tables (Required)

List of table names that SQL queries can access. Validates that queries only use expected tables.

source.address (Optional)

Contract address for the data source. Enables SQL query reuse through sg_source_address() function calls instead of hard-coding addresses.
In SQL queries:

source.startBlock (Optional)

Minimum block number for SQL queries. Used as the indexing starting point. Default: 0

source.endBlock (Optional)

Maximum block number for SQL queries. Indexing completes when reaching this block. Default: Maximum possible block number

Transformer Configuration

The transformer section describes how source tables transform into subgraph entities.

transformer.apiVersion (Required)

Transformer version. Each version may have different features.
Currently, only version 0.0.1 is available.

transformer.abis (Optional)

List of ABIs for extracting event signatures in SQL queries. Enables sg_event_signature('CONTRACT_NAME', 'EVENT_NAME') calls that resolve to full event signatures. Default: Empty list
In SQL queries:

transformer.tables (Required)

List of transformed tables extracting data from source tables into subgraph entities.

transformer.tables[i].name (Required)

Name of the transformed table. Must reference a valid entity name from the subgraph schema.

transformer.tables[i].query (Optional)

Inline SQL query that executes on the AMP server. Useful for simple queries.
If query is provided, the file field is ignored.

transformer.tables[i].file (Optional)

IPFS link to a SQL query file that executes on the AMP server.
If query is not provided, file is used. One of query or file must be present.

SQL Query Requirements

Reserved Prefix

Table names, column names, and aliases must not start with amp_ - this prefix is reserved for internal use.

Block Numbers (Required)

Every SQL query must return the block number for every row. Graph Node looks for block numbers in these columns (in order):
  • _block_num
  • block_num
  • blockNum
  • block
  • block_number
  • blockNumber

Block Hashes (Expected)

Every SQL query should return the block hash for every row. Graph Node looks for block hashes in:
  • hash
  • block_hash
  • blockHash
If a table doesn’t contain the block hash column, retrieve it by joining with another table that has it on the _block_num column. If not provided, Graph Node attempts to fetch it from source tables.

Block Timestamps (Required for Aggregations)

Required for subgraphs using aggregations. Graph Node looks for block timestamps in:
  • timestamp
  • block_timestamp
  • blockTimestamp
Retrieve via join if the table doesn’t have a timestamp column. Graph Node attempts to fetch from source tables if not provided.

Complete Examples

Advanced Features

Schema Generation

AMP-powered subgraphs support automatic GraphQL schema generation based on SQL query schemas. To enable, remove the schema field from the manifest:
Generated entities are immutable.
For flexibility and control, manually created GraphQL schemas are preferred.

Aggregations

AMP-powered subgraphs fully support subgraph aggregations for complex aggregations on indexed data.
See the aggregations documentation for details.

Composition

AMP-powered subgraphs fully support subgraph composition for applying complex mappings on top of AMP-indexed data. See the composition example for details.

Environment Variables

Additional configuration for AMP-powered subgraphs:

Example Configuration

Metrics

AMP-powered subgraphs report to existing deployment metrics and add new ones:

Existing Metrics

  • deployment_status: Current deployment status
  • deployment_head: Current block height
  • deployment_synced: Whether deployment is synced
  • deployment_blocks_processed_count: Total blocks processed

New Metrics

  • deployment_target: Maximum block number currently available for indexing
  • deployment_indexing_duration_seconds: Total duration of deployment indexing in seconds

Extended Metrics

  • deployment_sync_secs: Extended with AMP-specific indexing process sections

Monitoring Example

Resources

AMP Subgraph Examples

Complete examples with deployment and query patterns

Aggregations Documentation

Learn about subgraph aggregations feature

Composition Example

Composable subgraph patterns and examples

Configuration File

Advanced TOML configuration reference

Performance Benefits

AMP-powered subgraphs offer significant performance improvements:

Faster Indexing

Reduce indexing time from days/weeks to minutes/hours

Lower Resources

Less compute and storage required

SQL Flexibility

Full SQL power for complex data transformations
Performance gains depend on subgraph complexity and data volume. Simple subgraphs may see 10-100x speedup, while complex ones still see significant improvements.