Make.com Data Store Tutorial: How to Use Persistent Storage in Your Automations

Make.com scenarios are stateless by default. Each execution runs independently with no memory of previous runs. That is fine for simple trigger-action automations where every execution is self-contained. But many real-world automation scenarios need to remember something: whether a contact has already been processed, what the last value of a counter was, whether a specific event has happened before.

Make.com Data Stores solve this. They are a lightweight key-value database built into Make that persists between executions. You read from them, write to them, and use the stored values to make decisions in your scenario logic.

This tutorial covers everything about Make.com Data Stores: what they are, how to set them up, the key operations, and the practical patterns that make them useful in production automations. It builds on the fundamentals in Make.com Tutorial for Beginners.

What Data Stores Are

A Data Store in Make.com is a simple structured database with rows and fields. You define the schema — what fields each record has and their data types — and then use Data Store modules in your scenarios to create, read, update, search, and delete records.

Data Stores persist between scenario executions. A value written in one run is available in the next run, and in runs that happen days later. This makes them the right tool for anything that needs to survive beyond a single execution.

The size limits depend on your Make plan. Free plans get a small allocation. Paid plans get more. Data Stores are not designed to hold millions of records — for large data needs, use an external database. But for automation state management, counters, processed-record tracking, and small reference data sets, they are perfectly sized.

Creating a Data Store

In Make.com, go to Data Stores in the left sidebar and click Create a new data store. Give it a name that identifies its purpose: Processed Lead IDs, Counter Store, Last Sync Timestamps, and so on.

Define the data structure by adding fields. Each field has a name and a type: text, number, boolean, date, array, or collection. For simple use cases like tracking processed IDs, you might just need an ID field of type text. For more complex cases like storing configuration data, you add multiple fields.

Data Stores have a Key field by default — a unique identifier for each record. You set the Key value when creating or updating records.

The Core Data Store Modules

Add/Replace a Record. Creates a new record or replaces an existing one with the same Key. Use this to store data you want to persist. If the Key already exists, the existing record is overwritten.

Update a Record. Modifies specific fields in an existing record without replacing the whole thing. Useful when you want to update one field while leaving others unchanged.

Get a Record. Retrieves a record by its Key. Returns the record's field values for use in downstream modules.

Search Records. Finds records matching a filter condition. Returns all matching records as an array.

Delete a Record. Removes a record by its Key.

Delete All Records. Clears the entire Data Store. Use carefully in production.

Check the Existence of a Record. Returns true or false based on whether a record with the specified Key exists. The most efficient way to check without retrieving the full record.

Pattern 1: Deduplication

The most common Data Store use case is preventing the same record from being processed twice. Without deduplication, scenarios that watch for new data can process the same item multiple times if the trigger fires repeatedly or if the scenario is re-run.

Workflow structure:

1. Trigger receives an event (webhook, new row in Sheets, etc.)
2. Extract the unique identifier for this event (email, order ID, lead ID)
3. Data Store Check Existence: does a record with this ID exist?
4. Router: if true (already processed), stop. If false (new), continue.
5. Process the event (create CRM contact, send email, etc.)
6. Data Store Add Record: store the ID with a timestamp so future executions skip it

This pattern ensures each unique event is processed exactly once, regardless of how many times the trigger fires or how the scenario is re-run. It pairs well with the retry logic covered in Make.com Error Handling, since retried executions should not create duplicate records.

Pattern 2: Counters and Rate Limiting

Data Stores track counters that persist across executions: total emails sent today, API calls made this hour, leads processed this week.

A daily email counter:

1. Scenario starts
2. Data Store Get Record with Key "daily-email-count-YYYY-MM-DD" (today's date)
3. If record exists and count >= limit, stop execution with a notification
4. If record does not exist or count < limit, continue with the email send
5. After sending: Data Store Update Record to increment the count by 1

This enforces a daily sending limit across all executions of the scenario, which is useful for respecting API rate limits or campaign frequency caps.

Pattern 3: Last Sync Timestamp

For scenarios that periodically sync data from one system to another, you need to track when the last sync ran so the next run only fetches records that changed after that point.

1. Scenario starts on a schedule
2. Data Store Get Record with Key "last-sync-timestamp"
3. Use the stored timestamp as the "since" parameter in the API query (fetch records modified after this time)
4. Process the returned records
5. Data Store Update Record with the current timestamp

The next run picks up where this one left off. Without this pattern, each sync run would fetch all records from the beginning, which is wasteful and can hit API rate limits. This is the same incremental sync logic that makes sense for the Airtable and Google Sheets sync patterns in Make.com Airtable Integration.

Pattern 4: Storing Configuration Data

For scenarios that need configuration values that change occasionally — API endpoints, threshold values, feature flags — a Data Store is a convenient place to store them without hardcoding in the scenario.

Create a Data Store called Scenario Config with text fields for each configurable value. Update the values in the Data Store when they change. The scenario reads them at runtime rather than having them baked into the module configuration.

This is particularly useful for multi-client scenarios where the same scenario logic needs to run with different configuration values per client. Each client has their own Config record in the Data Store, and the scenario reads the right one based on which client triggered the execution.

Pattern 5: Queue Management

For scenarios where work needs to be distributed across multiple executions — processing a large batch of records without hitting timeout limits — a Data Store acts as a simple queue.

1. A loading scenario adds items to the Data Store with a status of Pending
2. A processing scenario runs on a schedule, searches for Pending records, takes the next batch, processes them, and marks them as Completed or Failed
3. A monitoring scenario checks for Failed records and triggers alerts or retry logic

This pattern handles large volumes that cannot be processed in a single execution and provides visibility into processing status without an external queue system.

Limitations to Know

Data Stores are not a database. They lack joins, complex queries, indexes, and the performance characteristics of a real database. For more than a few thousand records or complex query requirements, use Airtable, a Google Sheet, or an external database via HTTP modules — see Make.com HTTP Module Tutorial for connecting to an external database via its API.

No real-time access outside Make. Data Store contents are accessible from Make.com scenarios but not directly from external systems via an API. If you need to read Data Store values from outside Make, you need a Make scenario that retrieves and returns them.

Storage limits apply. Check your plan's Data Store allocation on Make's pricing page before building systems that will accumulate large amounts of data. Plan accordingly and implement cleanup routines to delete old records.

Combining Data Stores With the JSON Validator

When storing complex data structures in Data Store text fields (serialised JSON), use the JSON Validator to confirm your JSON is well-formed against RFC 8259 before writing it to the store. Malformed JSON stored as text is harder to debug than a validation error caught before the write.

Building Better Stateful Automations

Make.com Data Stores bridge the gap between the stateless nature of individual scenario executions and the stateful reality of business processes that span time. Once you start using them for deduplication, timestamps, and counters, you will find them showing up in almost every non-trivial automation — they're a standard part of the toolkit I reach for on any client scenario that needs to remember state between runs.

If you want help designing a stateful automation architecture using Data Stores, or are hitting limitations that suggest you need an external data store, book a free 30-minute call. Bring the use case and the current scenario structure and we will work through the right approach.

Frequently Asked Questions

Can two scenario runs update the same data store record at once?

They can, and this is the trap behind every counter you will ever build in a data store. There is no atomic increment. A run reads the current value, adds one in a variable, then writes the result back. If a second run reads the same value before the first has written, both write the same number and one increment vanishes. It is fine for a low-volume counter that nobody audits. It is not fine for invoice numbers, sequence IDs, or anything where a collision is visible to a customer. If you need a guaranteed unique sequence, get it from the system that is going to store the record, not from Make.

What happens when a data store fills up?

Writes start failing. Storage is allocated per organisation on your Make plan, not per data store or per scenario, so a deduplication store that has been quietly accumulating one row per processed record for eight months can break an unrelated scenario that shares the same allowance. Deduplication stores are the usual culprit because nothing ever removes rows from them. Build a cleanup scenario the same day you build the store: a scheduled run that deletes records older than whatever window your duplicates actually arrive in, which is usually days rather than months.

Is there any way to undo a Delete All Records?

No. The module empties the store immediately and Make keeps no snapshot you can restore from. There is no confirmation step inside a running scenario either, so a Delete All Records module left connected after testing will wipe the store on the next scheduled run. If a store holds anything you would be sorry to lose, add a scheduled export scenario that writes the rows to a Google Sheet or an Airtable base on a timer. That export is your only backup.

Why does my last-sync-timestamp pattern keep skipping records?

Because the timestamp is written before the work is confirmed finished. The usual build reads the stored timestamp, fetches everything changed since, processes it, then writes the current time back. If the run fails halfway through processing but the timestamp has already been updated, the records that were never handled fall permanently outside the next query window and no error is ever raised. Write the new timestamp as the last module in the scenario, after the work, and take it from the timestamp of the newest record you actually processed rather than from the clock.

Should I use a data store or an external database?

Data stores are the right answer when the data exists only to serve the automation and nobody outside Make needs to read it: deduplication keys, sync cursors, small lookup tables, rate-limit counters. They stop being the right answer as soon as a human wants to browse the data, another tool needs to query it, the row count runs into the tens of thousands, or you need relationships between records. At that point put it in Airtable, a Google Sheet, or a real database and read from it with the HTTP module. Moving later is more work than choosing correctly now.

If you would rather have this built than build it, I take on Make.com and workflow automation work through Upwork.