Query-first design is a data-modeling method that starts with what an application must read and write, then shapes the schema to serve those operations. In ScyllaDB, storage layout affects cluster behavior: a useful design distributes data well while keeping each query focused on as few nodes as practical. Rather than beginning with relational entities and adding queries later, begin with requirements and make the required queries the design constraint. section 3.0 section 3.1
Work from requirements to schema in an iterative loop:
- List application requirements, including implicit work needed to create data that later reads depend on. section 3.1.1 section 3.1.3
- Turn each requirement into specific reads and writes. For a restaurant-review site, these include creating and reading articles, reading summaries by date, author, or score, and reading authors. section 3.1.2 section 3.1.3
- Identify what each query reads. Articles, article summaries, and authors become candidate tables; each ScyllaDB query accesses one table at a time. section 3.2
- Choose primary keys to identify rows and partition keys to spread data across the cluster. Add fields and data types required by the queries. section 3.4 section 4.7
- Review the complete design against requirements, then improve it. Recheck requirements after every change because correctness and improvement affect each other. section 5.1 section 5.1.2
The method often requires denormalization. If the same data must be loaded through different attributes, store it in multiple tables arranged for those access paths. This avoids relying on JOIN queries and avoids scans across every partition when a query does not use a primary key. Duplication is therefore a deliberate trade-off for directly supported queries. section 3.1.1 section 3.4
Restaurant-review summaries
A home page needs recent article summaries, author pages need summaries for one author, and a score view needs summaries ranked by score. Instead of one general summary table, the design uses article_summaries_by_date, article_summaries_by_author, and article_summaries_by_score alongside authors and articles. Each table supports a known query, with its own primary and partition key. Reviewing the whole design can reveal partition problems; date bucketing, for example, subdivides summaries to balance partition size against the queries needed to retrieve results. section 5.1.1 section 5.1.4 section 5.4
Figure 3.2 Query-first design guides you through taking application requirements and converting them to a ScyllaDB schema.
Trace the design path from requirements to queries, tables, partitioning, fields, and review; use it as a checklist before creating tables. section 3.1.1
