Sometimes you just need to remember a small thing. A counter. A cursor marking how far a sync got. A cached exchange rate that is good for an hour. A little bit of per-process configuration. None of these deserves a whole data-model type — with its properties, its relations, its permissions, its screens — and yet they still need to persist, surviving from one request to the next. Building a full type for a single counter is like renting a warehouse to store a sticky note.
The platform now has a key-value store for exactly this: a simple, persistent place to keep small pieces of state, available everywhere you write logic, without modelling anything.
Not everything deserves a data model
The data model is the right home for your real business entities — the things that need structure, relationships, access control, and history. But a lot of useful state is not a business entity. It is bookkeeping: where did I get to, how many have I seen, what did I cache, what is this feature's current setting. Forcing that kind of incidental state into a formal type adds ceremony out of all proportion to its value. The key-value store is the lightweight alternative for precisely those cases.
Remember a thing
At its heart the store is as simple as it sounds: set a value under a key, get it back later. The value can be anything JSON can describe — a number, a string, a list, a nested object — and it is stored durably, so it is still there on the next request, the next scheduled run, tomorrow. Because it lives with your tenant's data, it is included in backups and exports like everything else. Set, get, check existence, delete: the whole mental model fits in a sentence.
Counters that don't race
Counters look trivial until two things try to increment them at once, and a naive read-add-write quietly loses updates. The store offers an atomic increment for exactly this: bump a value by one — or by any amount — in a single safe step, with no chance of two runs treading on each other. Tallies, usage counts, "how many today" — the kind of number you want to trust — are a one-liner.
Group and query
Keys can be gathered into a named collection, which gives you a tidy way to list, count, and filter a logical group without wading through everything else. And because values are stored as structured data, you can query inside them — find every stored item whose status is open and whose priority is at least three, sorted highest first, for instance. It is not meant to replace real queries over your data model, but for small working sets it turns the store from a plain bucket into something you can actually search.
Expiry when you want it
Some state is only good for a while. When you set a value you can give it a lifespan — expire in an hour, or at a specific time — and once it lapses it simply disappears from every read and tidies itself up in the background. That makes the store a natural home for small caches and short-lived tokens, where you want the value to be there when it is fresh and gone when it is stale, without writing any cleanup yourself.
Shared across everything you build
The same store is reachable from every place you write logic — automations, custom apps, canvas items, and the console — as one shared keyspace for your tenant. A value written by an automation can be read by a custom app; a cursor set by a scheduled job is there for the next one. It is a common scratchpad your whole application shares, rather than a separate silo per feature.
Still not a replacement for the data model
It is worth being clear about the boundary, because using the right tool matters. When data needs a defined schema, relationships to other records, per-role permissions, or an audit trail, that is the data model's job and the store is the wrong choice. The store is deliberately lightweight: reach for it when the alternative would be an over-engineered type for something small, and reach for the data model when the data is genuinely part of your business structure.
Why it matters
A great deal of everyday logic needs to remember just a little, just for a while — and until now the only durable option was to model it as though it were a first-class entity. The key-value store removes that friction. It makes the quick things quick: a counter, a cursor, a cache, a small persistent object, without a schema, a migration, or a screen. It complements the data model rather than competing with it, and it slots into automations, custom apps, and the scheduler, giving everything you build a simple, shared, persistent memory to lean on.