Integrations
What Dataring connects to.
Dataring runs in your cloud account and reads metadata and access logs from the tools already in place. Nothing is migrated and no tool is replaced. Two kinds of connection: a handful of systems get Dataring’s own plugins for usage and actions, and everything else is mapped through the catalog.
How deep each connection goes.
Usage and actions
BigQuery
Snowflake
Airflow
Dagster
dbt
Dataring’s own plugins, for the systems where usage and actions live. BigQuery and Snowflake supply access logs and query history, read inside your account, so Dataring can say who reads each table and how often. Airflow and Dagster supply run history and, when you grant the optional write scope, receive the schedule and priority changes your team accepts. dbt supplies model lineage. Any warehouse works; Dataring is strongest on BigQuery.
Mapping through the catalog
Tables
Pipelines
Dashboards
Streams
Models
Files
Every system in the list below is mapped through the catalog layer Dataring deploys, or the catalog you already run, with lineage where the source exposes it. Descriptions, tags, owners, importance and classification are written back to the catalog once your team accepts them. The depth of each entry is the depth of its catalog connector: names, schemas, owners and lineage, not access logs.
Systems Dataring can map.
Grouped by what the system is. A system that appears twice has two connectors, for example Databricks as a warehouse and as a job runner. Entries marked beta are connectors the catalog ships as beta.
Warehouses, lakes and databases
BigQuery
Snowflake
Databricks
Unity Catalog
Redshift
Amazon Athena
AWS Glue
Azure SQL
SQL Server
PostgreSQL
MySQL
MariaDB
Oracle
DB2
SAP HANA
SAP ERP
Teradata
Vertica
Greenplum
Exasol
SingleStore
ClickHouse
Trino
Presto
Hive
Impala
Delta Lake
S3 data lake
GCS data lake
ADLS data lake
DynamoDB
MongoDB
Couchbase
Bigtable
Apache Doris
Apache Druid
Apache Pinot
Domo
Salesforce
SAS
SQLite
dbt
Cassandra (beta)
CockroachDB (beta)
StarRocks (beta)
TimescaleDB (beta)
QuestDB (beta)
IOMETE (beta)
BurstIQ (beta)
Epic (beta)
BI and dashboards
Looker
Tableau
Power BI
Metabase
Superset
Mode
Sigma
Lightdash
Redash
QuickSight
MicroStrategy
Qlik Sense
Qlik Cloud
SSRS
Domo
Grafana (beta)
Hex (beta)
Omni (beta)
Pipelines and sync
Airflow
Dagster
dbt Cloud
Fivetran
Airbyte
Databricks jobs
AWS Glue
Flink
Kafka Connect
NiFi
OpenLineage
Domo
Prefect (beta)
Spline (beta)
Streaming
Kafka
Redpanda
Kinesis
Pub/Sub
Storage
Amazon S3
Google Cloud Storage
Files and drives
Google Drive (beta)
SFTP (beta)
Custom drive
ML models
MLflow
SageMaker
Search
Elasticsearch
OpenSearch (beta)
Other catalogs
Alation
Amundsen
Apache Atlas
APIs
REST
Permissions, and anything missing.
Every connection runs on a metadata read scope plus read access to the access logs; the exact role names go to your engineer before the setup call. Writes are limited to the catalog fields your team accepts and, only if you grant it, orchestrator schedules and priority. The Security page lists each scope and what it can change.
Not on the list? Ask. The catalog adds connectors with each release, and any warehouse with access logs can supply usage.