Redshift to monday.com: how to get warehouse data onto a board

There are four realistic routes, and which one fits depends on who will maintain it and how many rows move.

Where this breaks: if the real goal is to show Redshift numbers next to board data, you may not need to copy anything. A BI tool reading both, or one summary figure written to a board each morning, is simpler than a row-for-row sync and cannot drift.

A monday.com board is a list of items with columns. A query result is a list of rows with fields. The mapping is direct, and most of the work is in the details. Each row becomes an item, one field becomes the item name, and the rest map to columns by column ID, not by the title you see on screen.

• Create items through monday's GraphQL API, passing column values as a JSON object keyed by column ID. Read the board's columns first and store the IDs; titles can be renamed, IDs cannot.
• Each column type takes its own value shape. Status columns want a label or index that already exists on the board, dates want a particular format, and people columns want monday user IDs, not names. Check the column-type reference in monday's developer documentation for each type you write.
• Decide what happens to a value that does not fit, such as a status label that is not on the board. Failing that one row and carrying on beats stopping the batch.
• Subitems, mirrors and formula columns are not plain writable fields. Write to the real columns and let monday compute the rest.
• Keep the board's columns to what the viewer needs. The warehouse can hold fifty fields per customer; the board should show the six that change a decision.

The first design decision is the row key: the field, or fields, that identify one thing in Redshift for good, such as an account ID. Not a name, and not a row position. Redshift does not enforce primary keys, so confirm the key is actually unique in your table before building on it.

1. 01Keep a mapping of row key to monday item ID, in a small database or in the sync tool's own storage. Do not write it back into the warehouse unless you are happy for the sync to write there.
2. 02Each run, read only rows changed since the last successful run, using an updated-at column, and keep the high-water mark only after the run succeeds.
3. 03For each changed row: if the key has an item ID, update that item; otherwise create the item and store the new ID straight away.
4. 04On a slower cycle, such as weekly, compare all keys in the warehouse with all mapped items. This is the only way to catch rows that were deleted or fell out of your query, because an updated-at filter cannot see them.
5. 05Decide what a vanished row means on the board: archive the item, move it to a Done group, or leave it. Do not delete automatically.

If the table has no reliable updated-at column, either add one upstream or hash the row's mapped fields and compare the hash with the one stored last time. Both are better than reprocessing everything each run.

Two systems, two sets of limits, and a sync lives between them. On the monday side, the API is GraphQL and applies rate and complexity limits that depend on your plan and change over time, so read the current figures in monday's developer documentation rather than trusting a number in an article. The practical rules do not change: send fewer, smaller requests, pace a backfill, and treat a limit response as a signal to wait and retry, not as a failure.

Where monday pushes to you, its own documentation says webhook deliveries retry once a minute for 30 minutes, so plan for the handler to be safe to run twice. Our monday.com app webhooks article covers that in detail. A warehouse sync mostly runs the other way, on a schedule, but the same idea applies to your retries: running a batch twice must leave the same result as running it once, which is what the key and mapping give you.

On the Redshift side, query in batches. Redshift is built for analytical scans, not for a lookup per row. Read the changed rows with one query, or export a larger set to S3 with UNLOAD, then process the file. If the tool you use cannot connect to Redshift directly, AWS's Data API lets a service run queries over HTTPS without managing a database connection; confirm in AWS's documentation that it suits your cluster type and permissions. Whichever way you connect, the cluster has to be reachable from where the sync runs, which for a private cluster is a networking question to settle with whoever manages your AWS account, before any build starts.

• When the board would hold more than a person can scan. A board with tens of thousands of copied rows is a worse database and a worse report. Send exceptions, summaries or the current week.
• When the data changes every few minutes and people need it exactly. A scheduled copy is always behind; show a live dashboard instead.
• When edits on the board should flow back to Redshift. That is a two-way sync with two owners per field, which is where systems start to disagree. Pick one owner per field. If the board has to feed the warehouse, read it out on a schedule and treat the warehouse copy as read-only.
• When the real need is reporting. Use a BI tool on Redshift and, if board data matters, load it into the warehouse and report there.

The direction we are asked about less often but see more value in is monday.com into the warehouse, so board activity can be reported alongside everything else. That is a read of the board on a schedule, with the same key and watermark ideas applied the other way.

We build this kind of sync as part of systems integration work. We have not built a Redshift to monday.com sync that we can point to as a case study, and nothing here describes client results. Our Make.com and monday.com platform pages cover what we do build on those tools.