Historian Bridge
Canary Historian™ data in Snowflake® and your data lake, with no gaps and no code
Publishes Canary Historian data to your own Microsoft Azure® storage as Apache Parquet™ and Apache Iceberg™ tables. Proven with Snowflake, open to any tool.
No loading warehouse. Snowflake reads the files where they land.
Historian data, ready for analytics
Point it at a Canary view and get tables your data team can query.
Raw readings
Every value, timestamp, and quality code, one row per reading.
Server-side aggregates
Or let Canary compute averages, like 10-minute time-weighted, and publish one row per interval.
Tag metadata
A daily snapshot of every tag and its properties, with the ones you pick promoted to columns.
Events
Canary Calcs & Events occurrences, with open events kept current until they close.
Quality preserved
Bad and uncertain readings keep their quality codes, so your analysts decide what to filter.
Configuration, not code
Adding a source takes a Canary view, a scoped token, and one config entry.
Lower Snowflake cost
Traditional ingestion runs a warehouse to copy every row into Snowflake storage. Here Snowflake reads the files where they already are.
No loading warehouse
No COPY INTO jobs and no warehouse running just to load data.
Stored once
Data lives in your own Azure Blob container at storage prices, not duplicated inside Snowflake.
Aggregate before you pay
Publish 10-minute averages instead of every raw reading where that's all your analysts need.
Partitioned by date
Files are organized by day, so queries read only the dates they ask for.
Built for Snowflake, not locked to it
Snowflake reads it in production today. The data lands in your own Azure storage, in open formats anything can read.
Snowflake-ready
Snowflake reads the Iceberg tables through an external volume, and the console generates a starter view for each source.
Open formats
Standard Apache Parquet files registered as Apache Iceberg tables, with no proprietary format to unlock.
Your storage, your data
Files go straight to your own Azure Blob container, with no third-party service in between.
Works beyond Snowflake
Any lakehouse, BI, or data-science tool that reads Parquet or Iceberg can use the same tables.
Complete, correct, and safe to re-run
A crash or outage costs you time, never data. Every run picks up where the last one stopped.
No gaps
Progress is saved only after data is committed, so an interrupted run is redone, never skipped.
Crash-safe at every step
Your tables only ever include complete batches, even if the host loses power mid-run.
Late data handled
Backfilled history in Canary is picked up automatically, and duplicate rows are removed.
New tags caught up
A tag added to the view joins the feed on the next run, along with its earlier history.
Failures contained
A tag that fails to read is held back on its own while every other tag keeps publishing.
Read-only on the historian
Uses scoped read-only tokens, never writes to Canary, and backs off when the historian is busy.
Set up and run from a browser
A signed installer and a local web console take you from install to a monitored feed without scripting.
Signed installer
One setup program brings everything it needs, and upgrades never touch your configuration.
Guided setup
Walk through historian, sources, storage, and alerts page by page, with connection tests and dry runs.
Live dashboard
See every source's status, which ones are catching up, and anything that needs a decision.
Alerts where you work
Health changes post to Microsoft Teams™, Slack®, or any webhook, including the all-clear.
Runs beside the historian
Lives on its own Windows host, on premises or in Azure, so publishing never competes with data collection.
What you need
Canary Historian 26.5 or later, network access to it, and an Azure Blob Storage container.
Ready to put your historian data to work?
Tell us what you want to do with your historian data, and we'll scope a pilot with you.