Skip to main content
The Mixpeek Vector Store (MVS) persists everything it owns — the write-ahead log, snapshots, and the cold tier — to object storage through a provider-agnostic layer. On dedicated and self-hosted deployments you can point that layer at your own bucket, on any supported provider, so your vector data lives in storage you control.
This is about where MVS stores its own data, not where you ingest from. To connect a bucket as an ingestion source, see Object Storage Integrations. The managed shared plane uses Mixpeek-operated storage; BYO object storage applies to single-tenant and self-hosted deployments and is configured at the deployment level (not a per-namespace setting).

​
Supported providers

MVS speaks the S3 API (via boto3) and the native GCS API. Any S3-compatible store works through the same code path — the only per-provider differences are the endpoint, region, and path-style addressing.
ProviderMVS_OBJECT_STORE_PROVIDERDocs
Amazon S3s3S3
Google Cloud StoragegcsGCS
Cloudflare R2r2R2
TigristigrisTigris
WasabiwasabiWasabi
Backblaze B2b2Backblaze
MinIOminioS3-compatible
DigitalOcean SpacesspacesS3-compatible
CephcephS3-compatible
LocalStack (dev)localstackS3-compatible
See all providers in the Object Storage overview.

​
Configuration

The object-store backend is resolved from environment variables on the MVS coordinator and shard pods:
VariableDefaultDescription
MVS_OBJECT_STORE_PROVIDERgcsProvider key from the table above.
MVS_BUCKET—Bucket that holds all MVS data. (Legacy alias: MVS_GCS_BUCKET — both must name the same bucket.)
MVS_OBJECT_STORE_ENDPOINT—Custom S3 endpoint. Required for R2, Tigris, and Wasabi; optional for MinIO/Ceph.
MVS_REGION—Region for S3-compatible providers.
MVS_PREFIXmvs/Global key prefix for all objects.
MVS_ENCRYPTION_KEY—Optional base64-encoded 32-byte key to encrypt all data at rest (see below).
The coordinator and the Rust shard must read the same bucket. Set MVS_BUCKET (or MVS_GCS_BUCKET) consistently across both — a split here causes cross-tenant namespace discovery. MVS fails fast if the two env vars disagree.

​
Credentials

Credentials are never stored in config — they’re resolved from the deployment environment:
  • S3-compatible: the standard AWS credential chain. Prefer an IAM role attached to the pods; otherwise set AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY. R2/Tigris/Wasabi/B2 issue S3 access keys you use the same way.
  • GCS: Application Default Credentials (workload identity / GOOGLE_APPLICATION_CREDENTIALS), or a service-account JSON supplied as a secret.

​
Endpoint and addressing notes

  • Endpoint required: R2 (https://<account_id>.r2.cloudflarestorage.com), Tigris, and Wasabi have no usable default — set MVS_OBJECT_STORE_ENDPOINT or MVS fails fast with a clear message rather than silently hitting AWS.
  • Path-style addressing is applied automatically for B2, MinIO, Ceph, and LocalStack (they only serve path-style); AWS/R2/Tigris/Wasabi use virtual-hosted style.

​
Encryption at rest

Set MVS_ENCRYPTION_KEY (base64-encoded 32 bytes) to transparently encrypt every object with AES-256-GCM. The object’s storage key is used as additional authenticated data (AAD), binding each ciphertext to its path. Migration is seamless: existing unencrypted objects stay readable while new writes are encrypted, so you can enable it on a populated bucket without a backfill.

​
Examples

MVS_OBJECT_STORE_PROVIDER=s3
MVS_BUCKET=my-mvs-data
MVS_REGION=us-east-1
# credentials via attached IAM role (recommended) or AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY