Databricks to Snowflake Data Sharing
You set up databricks to snowflake data sharing by reading common cloud storage files. Both platforms use open table formats or open sharing protocols on object buckets. Data teams often build batch pipelines that copy tables between these two systems. Copy jobs create duplicate files, add storage costs, and cause data drift. Teams also grant broad storage permissions to service accounts to keep pipelines running. Broad roles expose sensitive rows like emails and phone numbers across both platfo
Snowflake Access Control + End-to-End Encryption: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up databricks to snowflake data sharing by reading common cloud storage files. Both platforms use open table formats or open sharing protocols on object buckets. Data teams often build batch pipelines that copy tables between these two systems. Copy jobs create duplicate files, add storage costs, and cause data drift. Teams also grant broad storage permissions to service accounts to keep pipelines running. Broad roles expose sensitive rows like emails and phone numbers across both platforms.
How databricks to snowflake data sharing works in practice
Modern data platforms store table files in cloud object buckets you own. Databricks writes data using Delta Lake or Apache Iceberg table formats. You can configure Snowflake to read these exact same files in place. One common path uses Apache Iceberg metadata on your cloud storage bucket. Databricks generates the Iceberg metadata snapshot when a job updates a table. You then configure an external volume and catalog integration inside your Snowflake account. Another path uses the open Delta Sharing protocol to publish read-only tables. Both methods remove the need to copy raw parquet files across accounts. Your cloud storage role permissions govern which platform can read each bucket path. Inside each platform, catalog roles control which users can query the shared tables.
What native sharing solves and what it leaves open
Native file sharing stops teams from building brittle data copy pipelines. You pay for cloud storage once and query data from either engine. Platform admins manage table permissions inside Unity Catalog and Snowflake role hierarchies. Still, storage integrations and catalog roles only check who logs in. Once a user or script authenticates, the role permits every allowed query. Static roles cannot inspect individual SQL statements before the engine runs them. A developer with table permissions can run a bulk export of customer rows. Native sharing also creates two separate audit trails across the two platforms. When a shared service account runs queries, logs hide which human wrote the SQL. Admins must maintain duplicate masking rules in both catalogs for emails and card numbers. If one rule drifts out of sync, queries return unmasked values in results.
Securing shared data across analytics engines
Safe cross-platform sharing requires consistent controls over how humans and scripts run queries. Start by scoping cloud storage permissions to the exact prefix of shared tables. Never reuse one storage integration role across unrelated business units or environments. Next, audit your catalog permissions in both platforms to remove broad account roles. Separate the roles used by automated ingestion jobs from human analyst sessions. Review query logs in both platforms to find accounts that pull full tables. Replace shared database logins with individual user identities wherever analysts run ad-hoc queries. Apply consistent field masking rules so queries rewrite phone numbers and national IDs.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Snowflake Access Control + End-to-End Encryption: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can Snowflake read Databricks Delta tables without copying files?
Yes, you can configure external volumes and catalog integrations on shared cloud buckets. Databricks can also generate Iceberg metadata so both engines read the same files.
Does cross-platform sharing carry over column masking policies?
No, cloud storage files do not enforce catalog masking rules on their own. You must configure and maintain separate masking policies inside each query engine.
How do teams audit queries across both data platforms?
Each platform writes query history to its own internal system tables. Security teams must collect and join both logs to track data usage.
Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.
Teams test new role rules in staging first. Clear owner lists speed up each audit. Small role scopes cut down on risk. Regular log checks catch drift right away.