Data Store

Durable, authoritative per-world key–value storage. The source of truth for anything that must survive a session.

Helix.dataStore is HELIX's durable key–value store, scoped per world. It's the right place for anything that must outlive an instance: player progress, settings, world state. If you know Roblox, this is DataStore.

Data Store vs Memory Store

Data Store is durable and authoritative — the source of truth. Memory Store is volatile and fast — caches, leaderboards, matchmaking — and always expires. When in doubt about where data belongs, ask: "would losing this be a bug?" If yes, it's Data Store.

API

Prop

Type

Example

type Progress = { level: number; coins: number };

// load on join
const progress = (await Helix.dataStore.get<Progress>(`progress:${playerId}`)) ?? {
  level: 1,
  coins: 0,
};

// save on change
await Helix.dataStore.set(`progress:${playerId}`, progress);

UHelix::Get()->DataStore()->Get(
    FString::Printf(TEXT("progress:%s"), *PlayerId),
    FOnJson::CreateLambda([](const FHelixJson& Value) { /* ... */ }));

local key = "progress:" .. playerId
local progress = Helix.dataStore.get(key) or { level = 1, coins = 0 }
Helix.dataStore.set(key, progress)

Semantics & guarantees

Per-world namespace. Keys are isolated to your world; you can't read another world's data.
Authoritative. Writes are durable once set resolves.
Write from the server for value-bearing data. Persisting currency/inventory-adjacent state belongs to server-authoritative code — never let a client write its own balance. See the golden rule.
No direct database access. Creator code reaches persistence only through this API, never a raw DB connection.

Concurrency

Two instances of the same world can run at once. For counters or state edited by many players, prefer an atomic update pattern (pass the value's version you last read so a conflicting write is rejected) or use Memory Store's increment for hot, transient counters and flush to Data Store periodically.

Limits & quotas

Data Store is free for every world — no subscription required. Generous per-world quotas keep one world from degrading the service (or running up the bill); they're modelled on Roblox DataStore norms and can be raised for your world if you outgrow them:

Prop

Type

Exceeding a storage quota fails the write with a clear error; exceeding the write rate returns RateLimited — back off and retry. Reads aren't rate-limited at the API. Batch writes where you can, and prefer Memory Store for hot, high-frequency counters.

Reference

Web SDK → Helix.dataStore
REST → GET/PUT/DELETE /api/v1/data-store/:key and GET /api/v1/data-store?prefix= — the world is identified by the world-session token, never a path parameter, so a world can only ever reach its own namespace.
Guide → Persist player data

API

Example

Semantics & guarantees

Limits & quotas

Reference

On this page