Make.com Data Stores: Persist and Query Data Between Scenario Runs

Contains affiliate links. Disclosure.

Make.com Data Stores are built-in key-value databases that let your scenarios remember data between runs — without connecting to an external database.

Every Make scenario is stateless by default. Run a scenario twice and it has no memory of the first execution. Data Stores break that constraint. They give you a lightweight, persistent layer that lives inside Make, costs no extra infrastructure, and integrates directly with your modules through a dedicated set of operations.

This guide covers everything: creating a Data Store, defining its structure, performing all CRUD operations, running searches, and using Data Stores to solve three real-world problems — deduplication, API response caching, and scenario state management.

What is a Make.com Data Store?

A Data Store is a simple table-based database hosted inside your Make organization. Each store contains records — rows of data — defined by a Data Structure, which acts as a schema specifying the columns and their types.

Unlike a spreadsheet integration (Google Sheets, Airtable), a Data Store requires no external connection. It's entirely internal to Make, which means:

• No authentication overhead — no API keys, no connection renewal.
• Faster access — reads and writes happen within the same Make infrastructure.
• No external dependency — your scenario works even if third-party services are down.

When to use a Data Store (vs. Google Sheets or Airtable)

Use case	Best tool
Deduplication within a single Make workspace	Data Store
Shared data between team members outside Make	Google Sheets / Airtable
Caching API responses for a few hours	Data Store
Complex relational data with joins	External database (PostgreSQL, MySQL)
Tracking scenario execution state	Data Store
Reporting dashboards that non-Make users need to view	Google Sheets / Airtable

Data Stores are ideal for intra-scenario memory. They're not a replacement for a production database, but they're the right tool for lightweight persistence within Make.

---

Plan Limits for Data Stores

Make.com Data Stores are available on all paid plans. The Free plan does not include Data Stores.

Plan	Data Store size
Core	1 MB per store
Pro	10 MB per store
Teams	10 MB per store
Enterprise	Custom

Each record can hold up to 512 KB of data. The total size limit applies to all data stored in a single store. If you need to store larger datasets, you'll need to connect an external database using Make's database modules (MySQL, PostgreSQL, MongoDB, etc.).

---

Step 1: Create a Data Structure

Before creating a Data Store, you define its schema using a Data Structure. Think of this as the column layout for your table.

1. Go to Data Stores in the left sidebar of Make.
2. Click Add data store.
3. In the dialog, click Add next to "Data structure".
4. Name your structure (e.g., ProcessedEmails) and click Add item to define fields.

Each field has:

• Name — the column identifier (e.g., email, timestamp, status)
• Type — Text, Number, Boolean, Date, Array, Collection
• Required flag — whether the field is mandatory on record creation

Example structure for email deduplication:

Field name	Type	Required
email	Text	Yes
processed_at	Date	No
source	Text	No

---

Step 2: Create the Data Store

Once your Data Structure is ready:

1. Enter a name for the store (e.g., Processed Emails).
2. Select the Data Structure you just created.
3. Set the max size in MB.
4. Click Save.

Your Data Store now appears in the Data Stores section. You can click on it to browse records, add records manually, or clear all data.

---

Step 3: CRUD Operations in Scenarios

Make provides a dedicated Data Store app with the following modules:

Module	Operation	Description
Add/Replace a Record	Create/Replace	Inserts a new record or overwrites an existing one by key
Update a Record	Update	Modifies specific fields in an existing record
Delete a Record	Delete	Removes a single record by key
Delete All Records	Delete All	Clears every record in the store
Get a Record	Read	Fetches a single record by its unique key
Search Records	Read (filtered)	Retrieves records matching filter conditions
Check the Existence of a Record	Existence check	Returns true/false without fetching the data
Count Records	Aggregate	Returns the number of records

Add/Replace a Record

Use this module to insert new records or overwrite existing ones. Every record gets a unique Key — you define this yourself, or Make generates a UUID.

Configuration:

• Data Store: select your store
• Key: the unique identifier (e.g., {{email}} for email deduplication)
• Fields: map your scenario bundle values to store fields

Using a predictable key (like an email address or external record ID) is critical. It lets you use Check the Existence of a Record before adding — and it makes Get a Record fast because no search is needed.

Get a Record

Retrieves a single record by its exact key. This is O(1) — it doesn't scan the entire store.

Configuration:

• Data Store: select your store
• Key: the key to look up

If the record doesn't exist, the module returns an empty result (no error).

Search Records

The most flexible module: retrieve records matching one or more filter conditions.

Configuration:

• Data Store: select your store
• Filter: field + operator + value
  • Supported operators: Equal, Not equal, Contains, Does not contain, Greater than, Less than, Greater or equal, Less or equal
• Order by: field + ascending/descending
• Limit: max records to return (default: 10)

Example filter: status = pending returns all records where status equals "pending".

Searches perform a full table scan, so for large stores (thousands of records), prefer keyed lookups with Get a Record when possible.

Update a Record

Modifies one or more fields on an existing record without replacing it.

Configuration:

• Data Store: select your store
• Key: key of the record to update
• Fields: only the fields you want to change (unset fields remain unchanged)

This is different from Add/Replace a Record, which overwrites the entire record.

Delete a Record

Removes a record by its key. If the key doesn't exist, Make returns a success response (idempotent delete).

---

Real-World Pattern 1: Deduplication

Problem: Your scenario processes incoming webhook events (new leads, orders, emails). The same event occasionally fires twice. You want to skip duplicates.

Solution: Use a Data Store as a "seen IDs" registry.

Scenario structure:

1. Trigger — webhook receives new lead
2. Check the Existence of a Record — key: {{lead.id}}, Data Store: Processed Leads
3. Router — branch on existence result
   • Exists (true): stop processing (use a Break or terminate the path)
   • Does not exist (false): continue processing
4. [Process the lead — send email, update CRM, etc.]
5. Add/Replace a Record — key: {{lead.id}}, save processed_at: {{now}}

Key design choice: Use the source system's ID as the record key, not Make's internal ID. This makes the check unambiguous regardless of how many times the webhook fires.

Cleanup: For time-windowed deduplication (e.g., only deduplicate within 30 days), add a processed_at field and use a separate scheduled scenario to delete records older than your window with Search Records + Delete a Record.

---

Real-World Pattern 2: Caching API Responses

Problem: Your scenario calls an external API (weather data, currency rates, product catalog) on every run. The data changes slowly, but the API has rate limits or charges per call.

Solution: Cache the API response in a Data Store with a TTL.

Scenario structure (cache-aside pattern):

1. Get a Record — key: "exchange_rates_cache", Data Store: API Cache
2. Router — check if record exists AND cached_at is recent enough
   • Cache valid: use {{record.data}} directly, skip API call
   • Cache stale or missing: continue to next module
3. HTTP module — call the external API
4. Add/Replace a Record — key: "exchange_rates_cache", fields: data: {{api.result}}, cached_at: {{now}}
5. [Continue using the API data]

Tip: Store the API response as a JSON string in a Text field if the data structure is complex. Use Make's parseJSON() function to convert it back to a collection when reading.

TTL check in the Router:

{{dateDifference(now; record.cached_at; "minutes")}} > 60

This expression returns true if the cache is older than 60 minutes.

---

Real-World Pattern 3: Tracking Scenario State

Problem: A multi-step workflow (e.g., a multi-day email sequence or a paginated data export) needs to remember where it left off between scheduled runs.

Solution: Use a single Data Store record as a "checkpoint" or cursor.

Scenario structure (paginated export example):

1. Get a Record — key: "export_cursor", Data Store: Scenario State
2. Set Variable — offset = {{ifempty(record.offset; 0)}}
3. HTTP module — call API with ?offset={{offset}}&limit=100
4. [Process the returned page of data]
5. Update a Record — key: "export_cursor", fields: offset: {{add(offset; 100)}}, last_run: {{now}}
6. Router — if returned records < 100, the export is done
   • Done: Delete the cursor record or set offset back to 0

This pattern is useful for:

• Paginated API exports that span multiple scenario runs
• Multi-day drip campaigns (track which step each contact is on)
• Rate-limited bulk operations (process N records per run, advance the cursor)

---

Searching and Filtering Records

The Search Records module supports complex filter conditions. Here are practical examples:

Find all unprocessed records:

• Field: status, Operator: Equal, Value: unprocessed

Find records created in the last 24 hours:

• Field: created_at, Operator: Greater than, Value: {{addDays(now; -1)}}

Find records by partial text match:

• Field: email, Operator: Contains, Value: @gmail.com

Multiple filter conditions are combined with AND logic. To simulate OR logic, run two Search Records modules and merge their outputs using an Array aggregator.

Sorting and limiting:

• Sort by created_at descending to get the most recent records
• Set Limit to control how many records you iterate over (useful with an Iterator for batch processing)

---

Using the Make API to Manage Data Stores

For advanced use cases, you can manage Data Stores programmatically using the Make API.

List all data stores for a team:

curl -X GET 'https://eu1.make.com/api/v2/data-stores?teamId=YOUR_TEAM_ID' \
  --header 'Authorization: Token YOUR_API_TOKEN'

Create a data store:

curl -X POST 'https://eu1.make.com/api/v2/data-stores' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Token YOUR_API_TOKEN' \
  -d '{"name":"ProcessedLeads","teamId":123,"datastructureId":456,"maxSizeMB":10}'

Required API scopes:

• datastores:read — list stores, read records
• datastores:write — create, update, delete stores and records

The base URL differs by your Make zone (eu1, eu2, us1, us2). Check your Make dashboard URL to identify your zone.

---

Common Mistakes and How to Avoid Them

Mistake	Impact	Fix
Using auto-generated keys (UUIDs) for deduplication	Can't reliably check for existing records	Use the source system's ID as the key
Storing entire API responses without size checks	Hits the store's MB limit silently	Trim the payload to only the fields you need
Running Search Records on every scenario trigger	Slow and exhausts operations for large stores	Prefer Get a Record with a known key when possible
Never cleaning up old records	Store fills up, scenario fails	Add a scheduled cleanup scenario for old records
Relying on Data Stores for data that needs to survive team deletion	Data Stores are org-scoped; deleted with the team	Use an external database for critical long-term data

---

FAQ

What is a Make.com Data Store?

A Data Store is a built-in persistent database inside Make.com. It lets your scenarios store and retrieve data between runs without requiring an external database connection. Each store has a defined schema (Data Structure) and holds records that you can create, read, update, delete, and search.

How do I save data between Make scenario runs?

Use a Data Store with the Add/Replace a Record module at the end of your scenario. On the next run, use Get a Record or Check the Existence of a Record to read what was saved. This is the primary mechanism for giving Make scenarios persistent memory.

What is the size limit for Make.com Data Stores?

On the Core plan, each Data Store is limited to 1 MB. Pro and Teams plans allow up to 10 MB per store. Enterprise plans offer custom limits. Each individual record can hold a maximum of 512 KB of data.

Can I use Data Stores for deduplication?

Yes. This is one of the most common use cases. Store the unique ID of each processed item as the record key. Before processing a new item, use Check the Existence of a Record to see if it's already been handled. If it exists, skip it; if not, process it and add the key to the store.

Are Make.com Data Stores available on the Free plan?

No. Data Stores require a paid Make plan (Core or higher). On the Free plan, you would need to use an external storage solution like Google Sheets or a database connected via HTTP.

What's the difference between Add/Replace a Record and Update a Record?

Add/Replace overwrites the entire record with the new data you provide. Update only modifies the specific fields you include — other fields retain their existing values. Use Update when you want to change a single field (e.g., update a status field) without touching the rest of the record.

Can Data Stores be shared between multiple scenarios?

Yes. Data Stores are scoped to your Make team, not to individual scenarios. Any scenario in the same team can read from and write to the same Data Store. This makes them useful for cross-scenario communication and shared state management.

What happens if I try to get a record that doesn't exist?

The Get a Record module returns an empty bundle (no error). You can check for the empty result in a subsequent Router or Filter module using the isEmpty() function or by checking if a required field exists.

---

Next Steps

Data Stores give your Make scenarios persistent memory — the foundation for building reliable, stateful automation workflows. The three patterns covered here (deduplication, caching, state tracking) apply to the vast majority of real-world automation challenges.

Ready to start? Sign up for Make and create your first Data Store under the Data Stores section in the left sidebar.

For more automation tooling, explore how Apify can act as a data collection layer that feeds into your Make workflows — especially for web scraping pipelines where you need to process new data on a schedule and track which records have already been processed using a Data Store.