Databases, Tables and Columns

Databases, Tables and Columns

A database is a catalog entry and namespace. With the local backend it normally corresponds to a directory below the configured data path. A JSON backend configuration can instead map it to S3-compatible object storage or optional Ceph/RADOS.

A table contains its logical schema and one or more shards. Ordinary columns have stored values; computed and order-dependent columns have logical definitions whose physical caches may be created, repaired, invalidated, or evicted. SQL views store a SELECT definition and are expanded before logical planning.

Each table selects one of the safe, logged, sloppy, memory, or reconstructible cache engines. This changes durability and eviction semantics, not the SQL column types. See Persistency and Performance Guarantees before changing an existing table's ENGINE.

Primary, unique, and adaptive secondary indexes are represented separately from the column values. User and hidden triggers enforce constraints or maintain derived structures. Physical scans obtain shard access and read columns in batches; application code should use SQL rather than depending on internal shard or record-ID representation.

See Shards, RecordIDs, Main Storage, Delta Storage, Columnar Storage, and Storage Backends.