Polygon Stock API to Snowflake: How to Move Your Data
Move Polygon Stock API into Snowflake with Airbyte. Why a portfolio means one source per ticker, and why adjusted price history is rewritten behind you.
Moving Polygon Stock API into Snowflake gives you market history beside your own positions, costs and commitments. Price data is available anywhere; what a warehouse adds is the join to things only your organisation knows.
This guide covers the managed path with Airbyte. Two things shape the build: a source covers one ticker, so a portfolio is many pipelines, and adjusted prices change retroactively in a way your stored copy will not notice.
Polygon Stock API to Snowflake at a glance:
Why move data from Polygon Stock API to Snowflake?
Two situations account for most of these pipelines.
The first is the join. Market prices beside your own holdings, hedges or revenue exposure answer questions no market data provider can, because only you know what you hold and what you promised.
The second is a governed record for reporting that people rely on. If several systems need prices as they arrive rather than analysed later, Polygon Stock API to Kafka is the shape for that.
What do you need before you start?
Four things, and the first decides the size of the project:
A list of tickers, and an honest count. A source covers one ticker, so forty holdings is forty sources and forty connections. The Polygon source documentation covers the configuration.
An API key and a clear view of its tier. Free access is heavily rate limited, and that limit applies while you are running many sources rather than one, so a plan that works for a single ticker may not survive a portfolio.
A decided grain. The multiplier and timespan settings fix whether a row is a minute, a day or a week, and changing your mind later means resyncing rather than aggregating.
A position on adjusted prices. Whether you want prices as they were quoted or as they are restated after corporate actions is a question with no default right answer.
If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.
How do you build a Polygon Stock API to Snowflake pipeline in Airbyte?
Step 1: Multiply your tickers by your rate limit
Work out how many tickers you need and set that against what your Polygon tier allows, because these two numbers interact and neither is obvious alone. A free tier that feels generous for one symbol becomes the constraint on the whole project at forty, and discovering that after configuring thirty sources is a poor use of an afternoon.
Step 2: Configure the Polygon source
Click Sources in the left navigation, then New Source, and select Polygon Stock API, following adding a source. Supply the API key, ticker, multiplier, timespan and date range, then repeat per symbol. Name each source after the ticker so the list stays readable.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Point every ticker at the same schema, since a union view across them is what anybody will actually query.
Step 4: Create the connections and record the as-of date
Click Connections, then New connection for each ticker, selecting the stream and a sync mode. Keep the extraction timestamp visible in your views, because for this data knowing when a price was retrieved matters as much as the price.
Then write the union view naming the ticker, since forty tables is not something anybody should query directly.
What does a portfolio look like in practice?
A lot of near-identical configuration, because the ticker is part of the source rather than a stream selection. Each symbol needs its own source, its own connection and its own table, and the only thing distinguishing them is one field.
That is manageable for a handful and tedious beyond it, so generate them if your platform allows and name them systematically if it does not. The failure this prevents is subtle: forty hand-made sources will eventually disagree about multiplier or timespan, and a union view across tables at different grains produces a chart nobody can explain.
Rate limits compound it, since every source draws on the same allowance. On a free tier that turns into a queue, and on a portfolio of any size it is worth confirming the tier before building rather than after. The data itself is tiny, so nothing about the warehouse side is difficult; the awkwardness is entirely in the multiplication.
Why does stored history stop being correct?
Because adjusted prices are recalculated when corporate actions happen. A stock split does not change what a share traded at on the day; it changes what that price means in comparison to today, so adjusted series are rewritten backwards and a figure you stored last year is no longer the figure the provider would give you now.
Nothing in an incremental pipeline notices this. New rows arrive for new dates, old rows sit unchanged, and your warehouse quietly holds a version of history that has been superseded. The discrepancy is invisible until somebody compares a chart against the provider and finds the older part of the line in the wrong place.
So decide which series you want and behave accordingly. Unadjusted prices are stable once recorded and right for reconciling what was actually paid. Adjusted prices are right for comparison across time and need periodic refreshing, which on a dataset this small is cheap. Either way, keep the extraction timestamp and say in your documentation which of the two the tables hold.
Frequently asked questions
Can one source cover several tickers?
No. The ticker is part of the source configuration, so each symbol needs its own source and connection, with a union view bringing them together.
Why has my historical chart changed?
Adjusted prices are recalculated after corporate actions such as splits, so your stored copy can hold a superseded version. Refresh periodically if you use adjusted series.
Can I change the grain later?
Only by resyncing. The multiplier and timespan fix what a row represents, and you cannot recover finer detail from coarser rows afterwards.
My syncs are queuing.
Every source draws on the same rate limit, so a portfolio on a free tier will contend with itself. Check the tier against your ticker count.
Can I do this without writing code?
The pipelines, yes, though there is one per ticker. The union view and the join to your own positions are short SQL and they are the point.
Get your Polygon Stock API data into Snowflake
Multiply your ticker count by your rate limit before building anything, since each symbol is its own source and they all share one allowance. Fix the grain deliberately, because changing it means resyncing. Then choose between adjusted and unadjusted prices and write that down, because adjusted history is rewritten after corporate actions and your stored copy will not notice.
Airbyte's connector catalog includes 600+ pre-built connectors, so market data can sit beside the positions it affects. For accounting data into an operational database, see Xero to PostgreSQL, and for another financial source into a warehouse, Quickbooks to BigQuery.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.