Loading tutorials…
Loading tutorials…
Data Stores are Make's built-in persistent storage. Scenarios are stateless by default; Data Stores give you memory across runs. This is the difference between toy automation and production infrastructure.
Who this is forOwners with Make scenarios that need persistent state — deduplication, counters, lookup tables, queues, recently-processed lists. Required for any non-trivial automation that runs ongoing.
What you'll need
Step 1
Data Stores are great for: deduplication, counters, lookup tables, queues. NOT for: large datasets, complex queries, real-time analytics.
Dedup: track which records you have already processed. Before processing, check if the record ID is in the store. If yes, skip.
Counter: increment a number across scenario runs. Useful for rate limiting, batch tracking, or simple analytics.
Lookup table: small reference data (currency codes, country mappings, tier thresholds). Faster than calling an external API every time.
Queue: track items waiting to be processed. Pop one at a time on each scenario run.
NOT for: large datasets (use a real database), complex multi-condition queries (use SQL), or real-time analytics dashboards.
Step 2
Team → Data Stores → + Add Data Store. Define name, columns (key, value, additional fields), and capacity.
Open Team → Data Stores → "+ Add Data Store."
Name it clearly: "Processed Order IDs" or "Rate Limit Counters" — NOT "DataStore1."
Define the data structure: pick a "Data structure" template OR create new.
For dedup: key = the unique ID (e.g., order_id), value = timestamp processed.
For counter: key = the counter name (e.g., daily_count), value = number.
For lookup: key = the lookup field (e.g., country_code), value = the result (e.g., country_name).
Set max capacity. Free tier: 1MB. Core: 10MB. Plan based on expected row count × avg row size.
Save. The Data Store is now usable in scenarios.
Step 3
Scenario: trigger → Search Records in data store → if found, skip → if not found, process AND Add Record.
Use case: scenario pulls orders from a webhook. You only want to process each order_id once.
Structure: Webhook → Data Store "Search records" (search by key = order_id) → Router with 2 routes.
Route 1: filter "0 records found" → process the order → Data Store "Add a record" (key = order_id, value = current timestamp).
Route 2: filter "1+ records found" → skip (no action needed). Log the duplicate to a separate audit data store if you want visibility.
Now even if the webhook fires twice for the same order, you only process once.
Test by sending the same order_id twice. Verify it processes once and the second is logged as a duplicate.
Step 4
Scenario: read counter → increment → write back. Useful for rate limiting or batch tracking.
Use case: API allows max 100 calls/hour. You want to track how many calls you have made and stop before hitting the limit.
Create a Data Store "API Rate Counter" with key = "calls_this_hour" and value = number.
Scenario: Data Store "Get a record" (key = calls_this_hour) → Set Variable (counter = current_value + 1) → Filter (only continue if counter <= 100) → API call → Data Store "Update a record" (key = calls_this_hour, value = counter).
Add a separate scenario that runs hourly to reset the counter to 0.
This is the production pattern for handling rate limits with Make.
Step 5
When a scenario errors, write the bundle to a "Failed Bundles" data store. A separate replay scenario reads, retries, marks as replayed.
Create a Data Store "Failed Bundles" with columns: scenario_name, bundle_json, error_message, timestamp, replayed (bool).
In every scenario's error handler, add Data Store "Add a record" with the failing bundle data.
Build a separate "Replay Failed Bundles" scenario: Data Store "Search records" (filter replayed=false) → Iterator → for each: re-run the action → Data Store "Update record" (replayed=true).
Run the replay scenario manually after fixes, OR schedule it hourly to auto-recover.
This pattern is the difference between losing data on errors vs always recovering. Production scenarios should have this.
Step 6
Pre-load reference data (currency conversion, country mapping, etc.). Scenarios query instead of calling external APIs.
Use case: scenario needs to convert country codes to full country names. Calling an API each time costs ops + external rate limits.
Pre-load a Data Store "Country Names" with one record per country: key = "US," value = "United States," etc.
In scenarios, use Data Store "Get a record" (key = country_code) → returns the full name in <50ms.
Trade-off: data stores are small (1-10MB). Use for reference data with <10K rows. For larger datasets, use a real database (Airtable, Postgres via HTTP).
Refresh the lookup data periodically (monthly) via a separate "Refresh Lookups" scenario that fetches latest from an authoritative source.
Step 7
Team → Data Stores → [your store] → shows current size vs max. Set up alerts before hitting 80%.
Open Team → Data Stores → click your store name.
The page shows current size in KB vs max.
If approaching 80%, plan capacity expansion: upgrade plan OR archive old records.
For dedup stores: build a maintenance scenario that deletes records older than X days (you only need recent IDs for dedup; old IDs are irrelevant).
For counter stores: usually tiny. No maintenance needed.
For replay queues: archive replayed=true records after 30 days.
Common mistakes
Not deduplicating webhook-triggered scenarios
What goes wrong: Webhooks sometimes fire twice (network retries, source platform glitches). Without dedup, your scenario creates duplicate orders, sends duplicate emails, or charges customers twice.
How to avoid: For ALL webhook-triggered scenarios, add a Data Store dedup check at the start. Search by unique ID; skip if already processed.
Using a Data Store for large datasets
What goes wrong: You import 50,000 customer records into a Data Store for lookup. Hit capacity, query speed drops, scenarios time out, ops cost spirals.
How to avoid: Data Stores are for SMALL reference data (<10K rows). For large datasets, use Airtable, Google Sheets, or a real database via HTTP. Data Stores are not a database.
Forgetting to write back after read
What goes wrong: Counter pattern: read counter = 5, increment to 6, but forget to write back. Counter stays at 5 forever. Rate limit broken, batch tracking broken.
How to avoid: Always pair "Get a record" with "Update a record" in counter or queue patterns. Read-modify-write must be complete.
Race conditions in concurrent scenarios
What goes wrong: Two scenarios increment the same counter simultaneously. Both read 5, both write 6. Real count is 7. Counter undercounts forever.
How to avoid: For concurrent counter scenarios, use the "Increment" Data Store action (atomic) rather than read-modify-write. Or accept ~5% undercounting and design around it.
No capacity monitoring
What goes wrong: Data Store hits max capacity, new records silently fail to write, scenarios continue without erroring, dedup breaks, duplicates start appearing.
How to avoid: Set a monitoring scenario that checks data store size weekly and alerts at 80%. Or build cleanup scenarios that prune old records automatically.
Recap
Done — what's next
How to set up error handlers in Make.com
Read the next tutorial
Hand it off
Data Stores are the production-grade missing piece in most DIY Make stacks. A specialist will retrofit dedup, counter, and replay patterns across your scenarios in one engagement. From $14-16/hr — most data-store retrofit projects land at $300-700.
See specialist rates
Data Stores are simple key-value stores native to Make — fast, small (1-10MB), and limited to key-based lookups. Real databases (Postgres, Airtable) support complex queries, joins, large datasets. Use Data Stores for small reference data and state; real databases for actual data storage.
Read/write operations count toward your monthly operations limit. 1 op per Search Records, Add Record, Get Record, Update Record. Storage itself is free up to the plan limit (1MB on Core, 10MB on Pro).
Yes — within the same team. Data Stores are team-level, accessible to all scenarios in that team. Useful for cross-scenario state (counters used by 5 different scenarios).
No hard cap on record count, but capacity is measured in bytes (1MB free, 10MB Core, more on Pro). With small records (100 bytes each), 10MB = 100K records.
Data Store: faster, cheaper, simpler, capped at 10MB. Airtable: richer features, larger capacity, more complex but slower. Use Data Store for small/fast state. Use Airtable for state that needs querying, filtering, or human access.
Make
Production scenarios will fail. APIs go down, rate limits hit, data is malformed. The question is whether your scenario recovers gracefully or silently breaks. Error handlers are the difference.
Make
Iterators and aggregators are how scenarios handle arrays — looping through records, batching API calls, building emails from lists. Get these wrong and one scenario can burn your entire monthly operations budget.
Make
Make has 1,500+ native app integrations. For the 10,000+ APIs that are not native, the HTTP module is your universal connector. Learn it once; integrate anything.
Make
Your scenario was working. Now it is failing. The diagnosis sequence specialists run is rarely random — there is a clear order that finds the root cause faster.