Logical Tables
Use logical tables when one query name should span multiple physical Pinot tables without exposing the partitioning scheme to users.
Last updated
Was this helpful?
Use logical tables when one query name should span multiple physical Pinot tables without exposing the partitioning scheme to users.
Logical tables are a naming and routing layer on top of physical tables. They let you split data by region, age, or operating mode while keeping one user-facing table name.
Use a logical table when the split is an implementation detail, not part of the query contract. Keep the physical tables aligned on schema, and use a reference physical table only as a metadata anchor.
Logical tables are most useful when you need one of these patterns:
Different physical tables per region or business unit.
Separate offline and realtime tables that still answer one business question.
Time-sliced tables that should be queried together.
Keep the underlying schemas aligned. Keep the logical name stable. Prefer this pattern only when the underlying split is operationally meaningful; do not use it to hide a modeling problem that should instead be solved with cleaner ingestion.
For hybrid-style layouts, make the time boundary explicit so Pinot does not double count overlapping data.
{
"tableName": "orders",
"brokerTenant": "DefaultTenant",
"physicalTableConfigMap": {
"ordersUS_OFFLINE": {},
"ordersEU_OFFLINE": {}
},
"refOfflineTableName": "ordersUS_OFFLINE"
}The original logical-table walkthrough lives in Logical Table.
This page covered when to use logical tables and how they hide physical table splits from readers.
Read Schema Evolution if the schema needs to grow after the table is already in production.
Last updated
Was this helpful?
Was this helpful?

