---
title: Limits
url: https://docs.vultr.com/products/storage/object-storage/limits
description: Defines the maximum capacity and usage restrictions for Vultr Object Storage subscriptions.
publish_date: 2024-11-27T19:49:58.620806Z
last_updated: 2026-05-26T19:42:14.958890Z
---

# Vultr Object Storage Subscription Limits

Vultr Object Storage is an S3-compatible solution that offers on-demand data storage for business assets. The solution is ideal for storing web application assets like images, audio, and videos.

## Operations Limit

Vultr Object Storage subscription operations refer to the activities and processes involved in managing a Vultr Object Storage subscription. This includes creating, maintaining, and scaling Vultr Objects Storage subscription.

* Each Vultr Object Storage subscription supports up to **400 operations per second**, allowing for high-performance data access, retrieval, and management at scale.

## Bucket Limit

Vultr Object Storage subscription buckets are the primary organizational units used to store and manage data. A bucket acts as a container for objects (files, metadata, and data streams) and provides a structured way to store and retrieve data. Buckets are globally unique within the Vultr Object Storage system and can be configured with specific permissions, settings, and access controls to manage how data is stored, secured, and accessed.

* Each Vultr Object Storage subscription includes a default **limit of 100 buckets**, with the option to request an increase by contacting support.
* Bucket names must be between **3 and 63 characters** long. If you plan to enable Archival Storage on a bucket, the name must be between **3 and 53 characters** at creation time. Archival Storage cannot be enabled on a bucket whose name exceeds 53 characters.

## Storage Tiers and Performance

Vultr Object Storage offers multiple tiers to support a variety of workload needs. Choose the tier that best matches your performance and cost requirements:

* **Accelerated**: High-performance NVMe storage optimized for write-intensive workloads.  
  Up to **10,000 IOPS**, up to **5 Gbps** throughput.

* **Performance**: Low-latency NVMe storage designed for datacenter workloads.  
  Up to **4,000 IOPS**, up to **1 Gbps** throughput.

* **Premium**: Reliable and durable storage for general-purpose applications. Stored on HDD, indexed on SSD.  
  Up to **1,000 IOPS**, up to **800 Mbps** throughput.

* **Standard**: Cost-effective, high-availability bulk storage. Stored on HDD, indexed on SSD.
  Up to **800 IOPS**, up to **600 Mbps** throughput.

* **Archive**: Ultra low-cost storage for infrequently accessed data. Base price is **$6/month**, which includes **100 GB** of unarchived storage, **1000 GB** of archive storage, and **1 TB** of bandwidth. Additional unarchived storage is billed at $0.018 per GB-month; additional archive storage at $0.006 per GB-month; additional bandwidth at $10/TB. Archived objects appear as 0 bytes in the bucket and must be restored before they can be accessed directly. Shares the same rate limits as Standard.

## Archival Storage Limits

Vultr Archival Object Storage is available on Standard (tier_id 2) and Archive (tier_id 6) subscriptions. Accelerated, Performance, and Premium tiers do not support archival.

### Bucket Versioning

* Bucket versioning cannot be enabled while Archival Storage is active on a bucket. Disable Archival Storage first.
* Once versioning is enabled on a bucket — even after Archival Storage has been disabled — that bucket is permanently ineligible for Archival Storage.

### Restore Window

* Objects retrieved via a direct download are available for **7 days** before returning to archive-only state.
* Objects retrieved via an explicit restore request are available for the number of days specified in the request.
* Restored objects are billed at the Standard storage rate ($0.018 per GB-month) during the restore window, in addition to the Archive storage rate.

### Lifecycle Policy Execution

* Lifecycle policies run at **00:00 UTC** each day. The actual transition time depends on cluster load at the time the policy runs.