The Snowflake Marketplace is a catalog of third-party datasets that any Snowflake account can mount and query directly — no ETL, no API keys, no separate data infrastructure. The data stays with the provider; you pay to query it from your account.
This page is part of Milemarker's Snowflake cluster for financial services. See the Snowflake for Financial Services pillar for the full landscape, or explore related capabilities: Snowflake Data Sharing and Cortex AI.
What's on the Marketplace That Matters for Wealth Management
The Snowflake Marketplace has hundreds of listings across dozens of categories. Most of them are irrelevant to wealth management. The following are the categories and specific providers that matter — based on what wealth management analytics teams are actually using.
How Marketplace Listings Work Technically
Snowflake Marketplace listings are built on the same data sharing technology that underlies Snowflake Data Sharing generally — the provider's data stays in their Snowflake account, and consumers receive read-only access without any data being copied. The Marketplace adds a discovery and licensing layer on top: providers publish their datasets with documentation, pricing, and sample data; consumers browse and subscribe through a self-service interface.
Discovery. Trial. Subscribe. Query.
A Snowflake user browses the Marketplace, finds a relevant listing, and requests a sample or free tier. After evaluating the sample data against their use case, they subscribe — entering a licensing agreement with the provider and paying the subscription fee. Snowflake provisions the listing as a read-only database in the consumer's account. From that point, the consumer queries the listing data the same way they query any other table in their warehouse — using standard SQL, from any tool connected to their Snowflake account.
No API credentials to manage. No ETL pipeline to build. No separate data environment to maintain. The listing appears as a database with tables that can be queried and joined immediately.
Billing Models
Marketplace listings use one of three billing approaches. Free listings — primarily government data, public datasets, and provider samples — require no payment. Subscription listings charge a fixed periodic fee (monthly or annual) set by the provider, paid through Snowflake billing. Usage-based listings charge per query or per row accessed, which can create cost variability for high-volume workloads. In all cases, the consumer's Snowflake compute credits are consumed when queries execute — this is separate from and additive to any subscription fee paid to the provider.
Free vs. Paid Listings
The Marketplace has a meaningful free tier. BEA and FRED economic data, several public market data samples, and some demographic data layers are available at no subscription cost. The free listings are often sufficient for macro context use cases and for evaluating whether a category of data is useful before committing to a paid subscription. Paid listings cover proprietary data — commercial pricing data from FactSet or S&P, ESG ratings from MSCI, firmographic data from Dun & Bradstreet — where the provider has made significant investment in data collection and methodology.
Real Use Cases for Wealth Firms
Portfolio ESG Scoring
Join client portfolio holdings (by ISIN or CUSIP) against MSCI ESG or Truvalue scores to calculate household-level ESG ratings. Advisors at Flat Iron Wealth, for example, can filter their entire book to identify clients with ESG-stated preferences whose portfolios score below a threshold — and initiate the rebalancing conversation before the client asks.
Benchmark Comparison
Pull S&P sector index constituents and return data from a Marketplace listing and join against client equity holdings to produce sector attribution relative to benchmark. The query that would have required assembling two separate data feeds, normalizing identifiers, and writing a custom attribution calculation becomes a SQL join between two databases in the same warehouse.
Prospect Enrichment
Join CRM prospect records against Dun & Bradstreet or Crunchbase firmographic data to identify high-priority prospects based on company revenue, funding stage, or recent growth events. Wealth teams targeting business owners or executives can filter their outreach list to those whose companies meet specific financial criteria — without any manual research or separate data subscription.
Macro Context in Advisor Dashboards
Pull FRED interest rate series, GDP growth, and inflation data from free Marketplace listings and join against portfolio return timelines to give advisors an at-a-glance macro backdrop for client conversations. This contextual layer has historically required a separate data feed or manual sourcing from a Federal Reserve website; from the Marketplace it is a SQL join that updates automatically when FRED publishes new data.
What's NOT on the Marketplace
Honest guidance on where the Marketplace has real gaps — which are meaningful for some wealth management use cases.
The Marketplace is not a replacement for all data relationships. Some data types and providers are not represented, and attempting to solve for them with Marketplace substitutes will lead to frustration. Know the gaps before committing to a Marketplace-first data strategy.
- Tick-level intraday market data — End-of-day pricing is well-represented. Tick-by-tick intraday data from all exchanges is not, and what exists may not meet the depth or historical coverage required for algorithmic trading or intraday risk management use cases.
- Custodian position and transaction data — Schwab, Fidelity, and other custodians are not distributing client account data through the public Marketplace. These relationships use Private Listings or direct Snowflake Data Sharing arrangements, which require bilateral agreements with the custodian.
- Niche alternative data — The long tail of alternative data providers — specialized satellite imagery analysts, specific consumer panel providers, proprietary earnings call transcript processors — may not have Marketplace listings yet. Direct data agreements remain necessary for these.
- Proprietary index methodologies — Certain index providers do not make their index constituents and weights available as queryable data through the Marketplace; licensing arrangements restrict distribution to specific use cases and delivery mechanisms.
- Real-time streaming data — The Marketplace is optimized for batch-updated datasets, not real-time streaming. Firms with real-time risk monitoring or live pricing requirements should evaluate whether Marketplace refresh cadence meets their latency needs before designing against it.
Cost Considerations for Marketplace Data
Marketplace pricing is transparent for listed subscriptions but has cost dynamics that deserve careful evaluation before committing.
| Cost Dimension | Traditional API/ETL Feed | Snowflake Marketplace |
|---|---|---|
| Data subscription fee | Annual contract with provider; often negotiated; includes volume tiers | Set by provider; listed in Marketplace; may be higher for small subscribers with no negotiating leverage |
| Infrastructure cost | ETL pipeline to ingest, normalize, and store; ongoing engineering maintenance | None — no ingestion pipeline; no separate storage |
| Engineering cost | Developer time to build, maintain, and monitor the feed | Minimal — subscription and mounting is self-service; no ingestion code |
| Query compute cost | Charged against internal warehouse; usually predictable | Charged in Snowflake credits per query execution; can amplify with large scans of market data |
| Data freshness risk | Feed failures or format changes require engineering intervention | Provider is responsible for maintaining the listing; no ingestion failure risk on consumer side |
| Time to first query | Weeks to months to build, test, and validate ingestion pipeline | Minutes to hours from subscription to first query |
Query Cost Amplification
The most important cost dynamic to understand is query amplification. Market data listings can be very large — years of daily pricing across thousands of securities across multiple data fields. A query that scans a large market data listing runs against the provider's storage, but the consumer pays for the compute. Poorly written queries (full table scans, non-predicate-filtered joins) against large listings can generate significant Snowflake credit consumption. Well-designed queries with appropriate date and identifier filters are essential for cost-efficient Marketplace usage at scale.
Governance over Marketplace subscriptions matters too. A Marketplace listing mounted in the production warehouse is queryable by any role with access to that database — including automated reports, BI tools, and scheduled queries. Without query management, a single misconfigured dashboard that refreshes hourly can generate unexpected compute costs against a large Marketplace listing.
Where Milemarker Fits
Milemarker pre-wires Marketplace datasets into the wealth data model so they are queryable as first-class citizens alongside natively ingested data. This means that when a firm subscribes to an MSCI ESG listing or a FRED economic data listing, the Marketplace database appears alongside the firm's CRM, portfolio, and custodian data in a unified query layer — no additional mapping required.
Milemarker's integration library covers the data relationships that the Marketplace does not: custodian feeds, portfolio management systems, CRM platforms, and compliance tools arrive through Milemarker's 130+ managed integrations, normalized into the same data model that Marketplace data joins against. The architecture Milemarker provides is The Infrastructure for Wealth — a single Snowflake environment where proprietary client data and third-party Marketplace data coexist, governed, and queryable together.
Pre-Mapped Identifiers
Milemarker's data model uses industry-standard security identifiers (CUSIP, ISIN, SEDOL) throughout, so Marketplace listings that use the same identifiers join without custom mapping logic.
Managed Governance
Marketplace subscriptions are governed by the same RBAC framework as the rest of the Milemarker data model — role-based access, query logging, and access auditing apply uniformly.
AI Over Marketplace Data
Cortex AI functions and Navigator agents can query Marketplace data as input context — enriching portfolio insights with ESG or macro data without any additional data movement or API integration.
Partner-Positioned
Milemarker augments Snowflake and Marketplace capabilities for wealth management. The Marketplace provides the data; Milemarker provides the data model, governance, and AI layer that makes it operationally useful.
For firms evaluating the broader data infrastructure picture, explore Snowflake for family offices, Snowflake for asset managers, and the Snowflake implementation guide for wealth management.