LandingAI ADE on Snowflake Marketplace: architecture, data flow, ZDR compatibility, document source options, and enterprise use cases for Snowflake data teams.
Enterprises already operating within Snowflake's data governance controls can run LandingAI ADE document extraction without moving their documents to a separate platform. ADE is available in the Snowflake Marketplace as a Native App installable directly into a Snowflake account and callable from Snowsight SQL worksheets, launched at Snowflake Summit 2025 where LandingAI was named the 2025 Startup Program Data Cloud Product Partner of the Year.
How the Architecture Works
Per the ADE Snowflake overview documentation, when a parsing or extraction procedure runs, the relevant files are sent to LandingAI's hosted ADE service for processing and results display directly in Snowsight.
Documents can be sourced from two locations:
- Documents staged in Snowflake. PDFs and images stored in Snowflake Stages are parsed by referencing the stage path. The app requires explicit stage access permissions, configured through the stage access documentation.
- Documents at publicly accessible URLs. The app can parse documents referenced by a public URL without staged file setup.
Billing for document processing is managed by LandingAI through the customer's ADE account, not through Snowflake's billing system.
ZDR Compatibility: A Critical Distinction
The Snowflake Native App and Zero Data Retention are mutually exclusive. Per the ADE Snowflake overview: the app cannot be used when ZDR is enabled on the LandingAI organization; ZDR must be disabled, or a separate organization without ZDR must be used.
This is the key architectural tradeoff: the Snowflake integration keeps extracted output within Snowflake's governance environment and eliminates downstream data movement, but document content transits to LandingAI's hosted service during processing. Organizations requiring that document content never leave their own infrastructure during processing should evaluate the containerized VPC deployment rather than the Snowflake Native App.
Two-Step Workflow: Parse Then Extract
The Snowflake Native App exposes two procedures that follow ADE's standard pipeline.
Parse. The parse procedure sends a document to ADE and returns structured Markdown and hierarchical JSON with page-level coordinates into a Snowflake output table. Documents can be referenced by staged file path or public URL. Optional parameters control the output table name and other parsing behavior. See Parse Documents for the full procedure reference and sample scripts.
Extract. The extract procedure runs field extraction on the parsed Markdown output, applying a customer-defined JSON schema to return specific fields. The schema can be passed inline or referenced from a staged schema file. Results are returned as a Snowflake table row. See Extract Fields from Parsed Output for required inputs, output table schema, and worked examples.
The two procedures can be chained: parse a batch of documents, store the Markdown output in a Snowflake table, then run extract on the stored Markdown to populate a structured field table for downstream analytics.
What Snowflake-Native Output Enables
Extraction results land directly in Snowflake tables, immediately available for native operations without export or ETL:
- Cortex Search integration. Parsed and embedded document chunks can be indexed with Cortex Search to enable vector similarity search and RAG queries across document archives, entirely within Snowflake.
- Cortex Analyst and Cortex Agent workflows. With Cortex Agent, users can orchestrate tools like Cortex Analyst to retrieve, reason over, and summarize extracted content, enabling end-to-end intelligence workflows inside Snowflake without external API dependencies.
- Direct SQL querying. Extracted fields populate Snowflake tables that are immediately queryable with SQL, joinable with existing Snowflake data, and usable in dbt models, BI connectors, or data applications without additional pipeline work.
Enterprise Use Cases
The Snowflake Native App is the appropriate deployment path when document extraction output needs to live alongside operational data in an existing Snowflake environment:
- KYC and financial onboarding. Financial institutions can automate document onboarding for KYC and loan applications by parsing incoming PDFs staged in Snowflake and extracting structured fields directly into compliance tables, as described in the ADE Snowflake launch announcement.
- Healthcare document intelligence. Eolas Medical built an Agentic RAG answer engine from healthcare institutional content using ADE, delivering validated support to medical professionals at the point of care, with the Snowflake integration keeping clinical content inside the customer's governed data environment.
- Document archive analytics. Organizations with existing document archives in Snowflake Stages can run bulk parsing and field extraction across historical document sets, populating structured tables that feed dashboards, compliance reports, and ML feature stores.
Installation
The ADE Snowflake Native App is installed from the Snowflake Marketplace using a LandingAI account and API key; after installation, stage access is granted for any Snowflake-staged files and the parse and extract procedures are callable from Snowsight SQL worksheets. See Install and Update for the complete setup checklist.
FAQ
Does the Snowflake Native App keep document data inside Snowflake during processing? No. When parsing or extraction is triggered, the relevant files are sent to LandingAI's hosted ADE service for processing, and results are returned into Snowsight. The Snowflake integration governs where extracted output lands and how it is stored and queried, not where processing occurs. Organizations requiring that document content never leave their own infrastructure during processing should evaluate the containerized VPC deployment option instead.
Can ZDR be enabled when using ADE on Snowflake? No. The ADE Snowflake Native App cannot be used when Zero Data Retention is enabled on the LandingAI organization. To use the Snowflake app, ZDR must be disabled, or a separate LandingAI organization without ZDR enabled must be used. Organizations that require both ZDR and Snowflake output should use the hosted ADE API with ZDR enabled and write parsed output to Snowflake via the Parse Jobs API output_save_url parameter, rather than the Native App.
How is billing handled for ADE on Snowflake? Document processing is billed through the customer's LandingAI account, not through Snowflake's billing system. Billing is managed by LandingAI based on credits consumed per document processed, consistent with standard ADE pricing. See ADE pricing for credit-based billing details and plan tiers.
What Snowflake capabilities become available once documents are extracted? Extracted fields land directly in Snowflake tables and are immediately available for SQL queries and joins with existing Snowflake data. Parsed Markdown can be embedded using Snowflake's text-to-embedding function and indexed with Cortex Search for RAG queries. Cortex Agent can orchestrate Cortex Analyst over extracted content to enable conversational intelligence workflows, all without data leaving Snowflake after extraction.