Introduction

In Amazon Redshift, storage size is usually something you estimate from system views rather than retrieve from one magical command. The practical workflow is to inspect table size first, then aggregate the same information up to the schema or database level.

Start With svv_table_info

For user tables, svv_table_info is usually the easiest place to start. It exposes one row per table together with operational columns such as row count and storage size in megabytes.

To inspect one table:

1select
2    "schema",
3    "table",
4    size as size_mb,
5    tbl_rows
6from svv_table_info
7where "schema" = 'public'
8  and "table" = 'orders';

That is enough for day-to-day questions such as "which table grew after the last load?" or "did yesterday's backfill double storage?"

If you prefer gigabytes, convert the value explicitly:

1select
2    "schema",
3    "table",
4    round(size / 1024.0, 2) as size_gb
5from svv_table_info
6where "schema" = 'public'
7  and "table" = 'orders';

Aggregate By Schema

Schema size is just the sum of the tables that belong to that schema. Redshift does not make this harder than it needs to be:

1select
2    "schema",
3    sum(size) as total_size_mb,
4    round(sum(size) / 1024.0, 2) as total_size_gb,
5    count(*) as table_count
6from svv_table_info
7where "schema" = 'analytics'
8group by "schema";

This is useful when teams are separated by schema and you want a rough ownership or chargeback view. The table_count column adds context, because a 500 GB schema made of two giant fact tables is a different operational problem from a 500 GB schema made of hundreds of small tables.

To see which tables dominate the schema:

1select
2    "table",
3    size as size_mb,
4    round(size / 1024.0, 2) as size_gb
5from svv_table_info
6where "schema" = 'analytics'
7order by size desc
8limit 20;

That query is often the fastest way to decide where cleanup or compression work should begin.

Estimate Database Size

At the database level, a common operational answer is to sum all visible table sizes:

1select
2    sum(size) as total_size_mb,
3    round(sum(size) / 1024.0, 2) as total_size_gb,
4    count(*) as table_count
5from svv_table_info;

This is not the same as a low-level cluster storage accounting view, but it is usually the number people want for application data footprint. For many dashboards and housekeeping tasks, that estimate is sufficient.

If you want a breakdown at the same time, group by schema:

1select
2    "schema",
3    sum(size) as total_size_mb,
4    round(sum(size) / 1024.0, 2) as total_size_gb
5from svv_table_info
6group by "schema"
7order by total_size_mb desc;

That gives you an immediate picture of where storage is going.

Read Size Together With Table Health

Storage numbers are most useful when you pair them with maintenance context. svv_table_info also exposes columns such as unsorted and stats_off.

1select
2    "schema",
3    "table",
4    size as size_mb,
5    unsorted,
6    stats_off
7from svv_table_info
8where "schema" = 'analytics'
9order by size desc
10limit 20;

A large table with a high unsorted percentage may need maintenance. A large table with stale statistics may produce poor plans even when storage itself is not the root cause. Size tells you where to look; the additional columns help explain what to do next.

Choose The Right Level Of Detail

When someone asks for "database size," the real question may be cluster billing, user-table storage, or the footprint of one application area. Those are related but not identical.

For most SQL users, table and schema summaries from svv_table_info are the right level because they map directly to work the team can do: archive data, drop old tables, revisit retention, or optimize the largest objects. If you need deeper cluster accounting, use cluster monitoring alongside these SQL views rather than expecting one table-level query to answer every storage question.

Common Pitfalls

• Looking for a single PostgreSQL-style size function and assuming Redshift exposes the same behavior.
• Forgetting that size in svv_table_info is already measured in megabytes.
• Filtering by table name without filtering by schema in an environment with repeated table names.
• Treating table size as the whole performance story instead of checking maintenance signals too.
• Calling the sum of visible tables a cluster-wide storage bill when the question is really about user data footprint.

Summary

• Use svv_table_info to inspect table size directly in Redshift.
• Sum the same size column to estimate schema size or overall visible database footprint.
• Convert megabytes to gigabytes explicitly when you want friendlier reporting.
• Read size together with columns such as unsorted and stats_off so the numbers lead to useful action.