Data Persistence
Where to put data when you need it to outlive a single call to your Cloud Function.
A Cloud Function on its own is stateless: every call starts fresh. To persist data between calls — service logs, configuration created by users, uploaded files — IXON Cloud provides two storage mechanisms scoped to your Cloud Function.
At a glance
| Mechanism | Best for | Not for |
|---|---|---|
| Document Store | Structured, JSON-like records you query, update, and aggregate. Backed by MongoDB. | Files and binary blobs. |
| Object Storage | Files: text documents, images, CAD drawings, exports — anything binary or unstructured. | Records you need to query by field. |
Scope and isolation
Both storage mechanisms are per-Cloud-Function:
- Each Cloud Function has its own Document Store collection. It cannot be shared between Cloud Functions, and therefore no other function can read or write to it.
- Each Cloud Function has its own Object Storage scope. Object Storage authorization is mediated by your function — see Object Storage for details.
If two Cloud Functions need to share data, they must both call out to a common service (typically via the API client or an external database).
In this section
- Document Store — storing and querying JSON-like records.
- Advanced Document Store Querying — operators, ObjectIds, and complex filters.
- Object Storage — uploading, downloading, and authorizing access to files.
Updated about 12 hours ago
