Datastore options
Marshal uses two datastores, and they do different jobs. Postgres holds everything that must survive: organizations, members, spaces, credentials, manifests and the audit trail. Redis holds short-lived state that Marshal can rebuild: sign-in tokens, live event streams, pod addresses, OAuth state and usage buffers. That difference decides where each one should run.
Which should I pick
- Postgres: use a managed Postgres 16 (Cloud SQL, RDS or your own) for anything you plan to keep. You get backups and a database that outlives the cluster. In-cluster Postgres on the k3s path is a fast way to evaluate, with no high availability and no backups.
- Redis: keep the bundled, in-cluster Redis on GKE, EKS and ArgoCD. Its data is rebuildable, so a managed Redis adds cost without adding safety. On k3s, the two datastores move together: a managed Postgres comes with a Redis you provide.
By target
| Target | Postgres | Redis |
|---|---|---|
| single-node k3s | In the cluster by default (postgres:16-alpine). Set provision_datastores = false with database_url and redis_url to use your own. | In the cluster by default (redis:7-alpine), or your own through redis_url |
| GKE | Your Postgres 16, such as Cloud SQL, through database_url (database_mode = "external", the default) | Bundled by default (redis_mode = "bundled") |
| EKS | Your Postgres 16 through database_url, or create_rds = true to have the installer create RDS. create_rds needs deploy_cluster = true. | Bundled by default (redis_mode = "bundled") |
| ArgoCD (any cloud) | Your Postgres 16, from a Secret you create (externalDatabaseSecret) | Bundled (bundledDeps.redis.enabled: true) or your own |
Requirements for a Postgres you bring are on AWS: before you install. They apply on every cloud.