Storage: gs:// (Google Cloud)
The same disaggregated ObjectStorage backend as s3://, pointed at Google Cloud Storage. Durability, scale-to-zero, branching, and the engine/API are identical — only the credentials and the egress-cost profile differ. See the shared model in the overview.
When to use it
- You're already on Google Cloud (e.g. running the server on Cloud Run next to a GCS bucket).
- You want disaggregated, scale-to-zero storage and prefer GCP's IAM/service-account model.
Open it
import { open } from "@twilldb/bun";
using db = open("gs://my-bucket/mydb");cargo run -p twill-server -- --listen 0.0.0.0:5433 --db gs://my-bucket/mydbBreakdown: gs://<bucket>/<db-prefix> names the GCS bucket and key prefix. The scheme is the only thing selecting this backend.
Credentials
Authenticate with a service account. Point the standard Google variable at the key file, or rely on the ambient credentials of the GCP runtime (Cloud Run, GKE Workload Identity, etc.).
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json
# On Cloud Run / GKE you can instead use the attached service account
# (Application Default Credentials) with no key file.Secrets stay in the environment
Keep the service-account key out of the repo and the connection string. Prefer Workload Identity / attached service accounts over key files where the runtime supports it.
What you gain (same as S3)
- Scale-to-zero — stateless compute idling to nothing; cold starts warm by WAL replay. See Scale-to-zero.
- Durable single-writer lease — CAS-epoch fencing against split brain.
- Copy-on-write branching — child key-prefix overlays, no page copies. See Branching.
Cost note
Like S3, GCS bills egress per GB, so cache misses on a cold cache incur transfer cost. For read-heavy or frequently-cold-started databases, weigh that against r2://'s zero egress — the engine behaves the same on all three.