Skip to content
Calcrivo

Redshift Storage Calculator

Project Redshift storage after columnar compression and growth, and compare RA3 managed storage against DC2 local capacity.

Inputs

TB
x

AZ64 and ZSTD encodings typically deliver 3x to 4x on warehouse data.

%
years
$/GB-month
TB

dc2.large offers 0.16 TB, dc2.8xlarge offers 2.56 TB.

Projected Compressed Size

11.20TB

Compressed Size Today

5.71TB

Projected Compressed Size

11 TiB

RA3 Managed Storage Cost

$275.25

DC2 Nodes Needed for Capacity

5nodes

Storage Model

RA3 decouples storage from compute — size the cluster for query concurrency and pay for storage separately

Step by step

  1. Values used

    Raw uncompressed data = 20 TB; Columnar compression ratio = 3.50 x; Annual data growth = 40 %; Plan ahead = 2 years; Node family = RA3 — managed storage billed separately; RA3 managed storage price = 0.0240 $/GB-month; DC2 storage per node = 2.56 TB

  2. Redshift Storage

    compressed = raw ÷ compression ratio; projected = compressed × (1 + annual growth)^years; DC2 nodes = ceil(projected TB ÷ TB per node).

  3. Projected Compressed Size

    = 11.20 TB

  4. Compressed Size Today

    = 5.71 TB

  5. Projected Compressed Size

    = 12,314,530,231,091

  6. RA3 Managed Storage Cost

    = 275.25

  7. DC2 Nodes Needed for Capacity

    = 5 nodes

  8. Storage Model

    = RA3 decouples storage from compute — size the cluster for query concurrency and pay for storage separately

How it works

Redshift stores data column by column and encodes each column separately, so 3x to 4x compression is normal and the raw figure badly overstates what you pay for. On RA3 that compressed volume is billed as managed storage at a flat GB-month rate and the node count is driven purely by query concurrency, whereas on DC2 the local SSD is bundled into the node and capacity alone can force nodes you do not need for compute. The managed-storage rate is an editable input with a realistic us-east-1 default — confirm current Redshift prices with AWS for your region. The RA3 versus DC2 decision is usually settled by this arithmetic: once capacity rather than concurrency dictates the DC2 node count, RA3 with separately billed managed storage is almost always cheaper.

Formula

Redshift Storage

compressed = raw ÷ compression ratio; projected = compressed × (1 + annual growth)^years; DC2 nodes = ceil(projected TB ÷ TB per node).

compression ratio
Raw bytes divided by stored bytes after column encoding
RA3 managed storage
S3-backed storage billed per GB-month, independent of node count
DC2 local storage
SSD attached to the node — capacity and compute scale together

Frequently Asked Questions

How is Redshift Storage calculated?

compressed = raw ÷ compression ratio; projected = compressed × (1 + annual growth)^years; DC2 nodes = ceil(projected TB ÷ TB per node). Redshift stores data column by column and encodes each column separately, so 3x to 4x compression is normal and the raw figure badly overstates what you pay for. On RA3 that compressed volume is billed as managed storage at a flat GB-month rate and the node count is driven purely by query concurrency, whereas on DC2 the local SSD is bundled into the node and capacity alone can force nodes you do not need for compute. The managed-storage rate is an editable input with a realistic us-east-1 default — confirm current Redshift prices with AWS for your region.

Why does Redshift Storage matter?

The RA3 versus DC2 decision is usually settled by this arithmetic: once capacity rather than concurrency dictates the DC2 node count, RA3 with separately billed managed storage is almost always cheaper.

What values do I need to enter?

This calculator takes 7 inputs: Raw uncompressed data, Columnar compression ratio, Annual data growth, Plan ahead, Node family, RA3 managed storage price, DC2 storage per node. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

What compression ratio should I assume?

Run ANALYZE COMPRESSION on a representative table rather than guessing. Wide fact tables with low-cardinality columns often exceed 4x, while pre-compressed or high-entropy data such as hashes and encrypted blobs may barely compress at all.

You might also need