A schema describes how data is organized for storage. In ScyllaDB, it is defined before reading or writing data, so the database knows what data to store and how to distribute it across a cluster. section 2.2 section 1.2.5
A schema begins with a keyspace, which houses tables. A table names its fields and primary key; the primary key determines how rows are identified and includes the partitioning information that affects where data lives. section 2.2.2 section 3.0
Restaurant review table
A food-review schema can store restaurant, ordered_at, food, and review fields. The primary key (restaurant, ordered_at, food) identifies each review while organizing rows around a restaurant. section 2.2.2
For ScyllaDB, schema design is query-first: start with application requirements, identify required queries and tables, choose keys and partitions, add fields, then verify and improve the design. Designing around partition-key queries balances load while limiting the nodes each request must contact. section 3.1.1 section 3.1
Query-first design asks:
- What application requirements and queries must the database support? section 3.1.1
- Which tables hold the queried data, and how can they be uniquely identified and partitioned? section 3.1.1
- Which fields belong in each table, and does the completed design meet requirements or need improvement? section 3.1.1 section 5.1
This differs from relational modeling habits. ScyllaDB does not support JOINs, so one-to-many access patterns need designs such as denormalization rather than relying on joins at query time. Changing a schema later can be high-friction and may require copying data into a new table. section 2.2.2 section 3.1.1
Figure 3.2 Query-first design guides you through taking application requirements and converting them to a ScyllaDB schema.
Follow the requirements-to-schema sequence when turning an application’s needed queries into tables, partitions, and fields. section 3.1.1
