---
title: Limitations & Tradeoffs
description: Understand ParadeDB's key limitations and tradeoffs
canonical: https://www.paradedb.com/docs/concepts/limitations
---

## Distributed Workloads

ParadeDB is designed to scale vertically on a single Postgres primary, and many production deployments comfortably operate in the 1–10TB range. Enterprise deployments can add read replicas for ParadeDB queries. The largest single ParadeDB database we’ve seen in production is 10TB.

For datasets that significantly exceed this scale, ParadeDB supports partitioned tables and sharded Postgres deployments with [Citus](/reference/sharding/citus) or [PgDog](https://pgdog.dev). If you're working with very large datasets, please [reach out to us](mailto:support@paradedb.com). We'd be happy to provide guidance and share our roadmap for [distributed query support](/project/roadmap#cloud-platform).

## Covering Index

The ParadeDB index is a covering index, which means it stores all indexed columns inside a single index per table. This
decision is intentional: by colocating all the relevant data, ParadeDB optimizes for fast reads and boolean conditions.

However, this means that all columns must be defined up front at index creation time. Adding or removing columns requires a `REINDEX`.

## DDL Replication

A well-known limitation of Postgres logical replication is that DDL (Data Definition Language) statements are not replicated. This includes operations like `CREATE TABLE` or `CREATE INDEX`.

If ParadeDB is running as a logical replica of a primary Postgres, DDL statements from the primary must be executed manually on the replica.
We recommend version-controlling your schema changes and using a migration tool or deployment automation to apply them consistently to both databases. See the [logical replication guide](/operate/deploy/logical-replication/getting-started) for more details.