---
title: Configure object storage
description: Configure InfluxDB 3 Core to connect to and use different object storage providers.
url: https://docs.influxdata.com/influxdb3/core/object-storage/
estimated_tokens: 581
product: InfluxDB 3 Core
version: core
publisher: InfluxData
canonical: https://docs.influxdata.com/influxdb3/core/object-storage/
date: '2025-07-17T14:14:17-06:00'
lastmod: '2025-07-17T14:14:17-06:00'
---

InfluxDB 3 Core can be configured to use different object storage providers
to store time series data in Parquet format. The process of configuring and
connecting to different object storage providers varies.
The following guides walk through configuring, connecting to, and using
different object storage providers as your InfluxDB 3 Core object store.

### [Amazon S3](/influxdb3/core/object-storage/s3/)

Use [Amazon S3](https://aws.amazon.com/s3/) as the object store for your
InfluxDB 3 Core instance.

### [MinIO](/influxdb3/core/object-storage/minio/)

Use [MinIO](https://min.io) as the object store for your InfluxDB 3 Core instance.
InfluxDB uses the MinIO S3-compatible API to interact with your MinIO server or
cluster.

### [Google Cloud Storage](/influxdb3/core/object-storage/gcs/)

Use [Google Cloud Storage](https://cloud.google.com/storage) as the object
store for your InfluxDB 3 Core instance.

### [Azure Blob Storage](/influxdb3/core/object-storage/azure/)

Use [Azure Blob Storage](https://azure.microsoft.com/products/storage/blobs)as the object store for your InfluxDB 3 Core instance.

## Object store requirements

InfluxDB 3 Core uses the object store as the source of truth for catalog
state.
The catalog write path relies on conditional PUT (PUT-if-not-exists) to
serialize catalog log writes, and every node depends on immediate visibility
of writes made by any other node.
Your object store deployment must provide the object store semantics
InfluxDB 3 Core depends on.

### Consistency semantics

InfluxDB 3 Core requires at least the following from any object store:

* **Strong read-after-write consistency**: a `GET` immediately after a
  successful `PUT` returns the new object.
* **Strong list-after-write consistency**: a `LIST` immediately after a
  successful `PUT` includes the new key.
* **Conditional PUT (PUT-if-not-exists) semantics**: concurrent creates of the
  same key serialize so that exactly one write succeeds and the other returns`AlreadyExists`.

A backend that violates these semantics can cause catalog split-brain, stale
reads on node startup, and unexpected node-state warnings.

#### Related

* [InfluxDB 3 Core configuration options](/influxdb3/core/reference/config-options/)

[object storage](/influxdb3/core/tags/object-storage/)[S3](/influxdb3/core/tags/s3/)