Skip to main content
Version: 5.6

Snowflake AI Data Cloud

The Snowflake AI Data Cloud is the cloud data platform from Snowflake. The “Snowflake AI Data Cloud” plug-in enables bidirectional data exchange between the OPC Router and this platform. Data can be both written to and read from the Snowflake AI Data Cloud. Various methods are available to specifically control costs, performance, and latency.

Architecture and Operation​

All operations are generally executed via a Snowflake warehouse. The warehouse handles the processing and calculation of all SQL queries and write operations.

warning

Cost Note: Every read or write operation via the warehouse incurs Snowflake credits. This also applies when Auto Resume / Suspend is enabled—costs are incurred as soon as the warehouse is active.

For pure ingest scenarios without queries, a cost-optimized alternative via Snowpipe is recommended.

Cost-Optimized Ingest Options (Write-Only)​

For write-only scenarios, in which the OPC Router exclusively inserts data into the Snowflake AI Data Cloud, two methods are available:

1. REST Plug-in → Snowpipe​

Using the REST plug-in, the OPC Router can send JSON or CSV data to a Snowpipe endpoint. Snowpipe loads this data asynchronously into the target tables without keeping a warehouse active.

Advantages

  • No active warehouse required
  • Highly cost-effective for continuous ingestion
  • Supports event-driven transfers (e.g., from production systems)

2. Cloud File Access Plug-in → S3 / Stage​

Alternatively, the OPC Router can write data directly to a cloud stage (e.g., Amazon S3). Snowpipe or a copy command in the Snowflake AI Data Cloud then automatically ingests the data.

Advantages

  • Batch processing of large data volumes
  • Ideal for periodic or buffered writes
  • No continuous warehouse load

Bidirectional Use​

The “Snowflake AI Data Cloud” plug-in supports not only writing but also reading and feeding data back. This enables the implementation of closed-loop scenarios (e.g., feedback from cloud analyses back to machines).

Two common approaches are available:

1. Transfer Status Trigger​

The Snowflake transfer status trigger initiates a transfer when a value in the monitored table is marked as not yet transferred. Once the transfer is complete, the record is marked as transferred or as failed. Failed transfers can optionally be retried any number of times using an additional counter.

Process

  1. The trigger monitors a defined table.
  2. A record is marked as not transferred (e.g., with 0) or is already added with that mark.
  3. As soon as such a record is detected, a transfer is triggered.
  4. After a successful transfer, the record is marked as transferred (e.g., 1) or as failed (e.g., 2).
  5. Failed transfers can optionally be retried multiple times, controlled by a retry column and the number of retries.

Advantages

  • Automated transfer process based on status values.
  • Retry mechanism for failed transfers increases reliability.
  • Status values and retry logic are freely configurable.
  • The number of records transferred per run can be limited.

Notes

  • The monitored table must have a primary key.
  • The status and retry columns must be initialized with 0 or the configured value—NULL is not allowed.
  • Sorting and filtering of the records to be transferred are configurable.

2. Data-Change Trigger​

The Snowflake Data Change Trigger monitors selected columns of a table and triggers a transfer when changes occur. Depending on the settings, changes are detected either via change notifications or through the polling interval configured in the plugin. A separate status column is not required.

Process

  1. The trigger monitors the selected columns of a table.
  2. A transfer is triggered when a change occurs in these columns.
  3. The Filter tab can be used to specify when a transfer is actually triggered.

Advantages

  • No additional status column required.
  • Easily integrable into existing tables.

Notes

  • The monitored table must have a primary key.
  • Optionally, a transfer can be triggered as soon as the connection is established.

Best Practices​

  • Choose warehouse size carefully: smaller clusters for continuous streams, larger ones only for batch loads.
  • Actively use "Suspend": automatic deactivation significantly reduces running costs.
  • Offload ingest asynchronously when real-time processing isn’t required (Snowpipe, REST).
  • Version schema changes to ensure stable transfers.
ScenarioMethodWarehouse RequiredCost-OptimizedRecommended For
Synchronous Inserts/SelectsWarehouse Connection✅❌Validations, small data volumes
Asynchronous ingest (REST)REST plug-in → Snowpipe❌✅Event/log data, edge → cloud
Batch Ingest (File Upload)Cloud File Access → S3/Stage❌✅Large data sets, periodic uploads
Read data from the Snowflake AI Data CloudSQL triggers, state or timestamp columns✅❌Return transfer or data feedback

See also​