Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The MuleSoft Object Store Connector provides key-value operations for application state, such as watermarks and access tokens. In CloudHub, Object Store v2 can share state across workers in a single application. It is useful for lightweight state, but it does not provide transactions or replace a database.

What the Object Store Connector does

The connector lets Mule flows store and manage data as key-value pairs. MuleSoft lists common uses including watermarks, temporal values such as access tokens, and user information; runtime components such as Cache and OAuth also use object stores. See MuleSoft’s Object Store Connector documentation.

  • Store writes a value for a key.
  • Retrieve reads a value by key.
  • Contains checks whether a key exists.
  • Remove deletes a key.
  • Clear clears stored entries.
  • Retrieve All and Retrieve All Keys return entries or keys.

A flow can use the default object store without declaring a custom store reference. Define a custom store when you need separately configured or partitioned state.

How Object Store v2 fits into CloudHub

Object Store v2 is a storage implementation for CloudHub applications. MuleSoft says it can share application data and state across runtime workers within one application. The Object Store Connector works with both v1 and v2, while the v2 REST API can also provide access to external applications. See the Object Store v2 overview and Object Store v2 API documentation.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For a CloudHub Mule 4 application, select v2 through Runtime Manager or the application’s configuration. The object store must be configured as persistent for the app to use v2; with persistent=false, the app does not use Object Store v2. Follow the version-specific Object Store v2 usage guide when configuring the application.

How Object Store v2 TTL works

TTL determines how long an entry remains available. In Object Store v2, the key detail is whether entryTtl is omitted or supplied: omission enables rolling behavior on Mule 4.2.1 and later, while supplying any value selects static behavior. Verify the runtime version and connector configuration because earlier Mule versions have different defaults. MuleSoft documents the behavior in its Object Store v2 overview and connector reference.

Rolling TTL: omit entryTtl

With rolling TTL, each key has its own expiration window. If an entry is accessed during the final seven days of its 30-day window, its lifetime extends for another 30 days. A Retrieve read extends the window; Contains, Clear, and Remove do not.

Static TTL: supply entryTtl

Static TTL counts from when the entry was created, and reading it does not extend its lifetime. The maximum is 2,592,000 seconds (30 days). Values above that limit are capped; zero or negative settings resolve to the maximum static duration in the reference.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Configuration checks

  • For rolling expiration, omit entryTtl rather than setting it to zero. entryTtl="0" selects static expiration at the 30-day maximum.
  • Check expirationInterval: the connector reference says Object Store v2 ignores entryTtl when this interval is nonpositive.
  • Confirm the runtime version and actual deployed configuration before relying on a default.

Object Store v2 limits and key constraints

MuleSoft documents no entry-count limit for v2 and a maximum value size of 10 MB in Base64-encoded size. Its FAQ states a maximum key size of 1024 bytes when encoded as UTF-8. CloudHub v2 does not support the pipe character (|) in keys and converts spaces to plus signs (+), so use predictable, compact keys that avoid these characters. See the Object Store v2 overview, Object Store v2 FAQ, and Object Store v2 usage guide.

Security and regional placement

MuleSoft describes Object Store v2 as using end-to-end TLS for transport and FIPS 140-2-compliant encryption for persistent storage. The service is co-located in the same region as the workers, according to its overview.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

When Object Store is the wrong choice

Object stores do not support transactional access or modification, so they are unsuitable when correctness depends on ACID guarantees or coordinated concurrent updates to the same key. MuleSoft’s connector documentation cautions: “They do not replace a database, and they are not suitable for every use case.” For those workloads, choose a storage system designed for the required transaction and concurrency guarantees.

Choosing v1, v2, or another storage system

Use the needs of the state and workload—not just the connector’s available operations—to guide the choice.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Decision factor What to check
Where state must be available v2 can share state across workers within a CloudHub application; determine whether the requirement is limited to that application or also involves external applications.
Expiration behavior Choose rolling TTL if access should extend an entry’s lifetime, or static TTL if it should expire relative to creation.
Key and value shape Check the documented size limits and key character handling before adopting a key scheme or storing large values.
Consistency needs If the design requires transactions, ACID semantics, or safe concurrent updates to one key, use a suitable alternative rather than assuming Object Store provides them.
Existing state Plan explicitly for existing v1 data; changing the implementation does not migrate it.

Plan a v1-to-v2 change carefully

MuleSoft states that v1 data—including watermarks and state held by other Mule components—does not carry over to v2. Back up any state the application needs before changing implementations. Reverting to v1 leaves the old v1 data there, but v2 state does not appear in v1. Treat the switch as a state migration that needs its own plan, not as a transparent storage toggle. See the Object Store v2 overview.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.