Skip to main content

Firestore

Google Cloud Firestore for state storage.

Setup

Quick Start

Behavior & Guarantees

The Firestore state store scopes credentials per client and writes hash fields atomically.

Credential isolation

Passing credentials_path= (or google_credentials in serve.yaml) scopes the service account to the firestore.Client instance only. Earlier versions mutated os.environ["GOOGLE_APPLICATION_CREDENTIALS"], which leaked one tenant’s credentials into every other Google Cloud client in the same process (Vertex AI, GCS, and others). Multi-tenant hosts and any process that mixes GCP credentials no longer need a workaround.

Atomic hash writes

hset(key, field, value) uses Firestore’s field-level merge (set(..., merge=True)) and hdel(key, *fields) uses DELETE_FIELD. Two writers updating different fields of the same key no longer clobber each other. Earlier versions did a read-modify-write of the whole value document.

TTL preservation

Because hset/hdel no longer rewrite the whole document, an existing expires_at (TTL) on the key is preserved across field updates. Earlier versions could reset the TTL when hset ran after expire(...).

Scoped credentials in serve.yaml

Credential isolation and atomic hash writes apply as of PraisonAI #4215. Field-level merge means concurrent writes to distinct fields are safe without external locking.

Best Practices

Pass credentials_path= per tenant so each firestore.Client carries its own service account. os.environ stays untouched, so other GCP clients in the process are unaffected.
Use hset(key, field, value) for per-field updates. Concurrent writers on different fields merge safely — no read-modify-write race.
Call expire(key, ttl) once. Subsequent hset/hdel calls preserve the existing expires_at, so the key still expires on schedule.

DynamoDB

AWS DynamoDB state store with atomic hash writes

Recipe Serve

Serve recipes over HTTP with scoped credentials