Should I design the database before building the site?

Start by describing the main things users need to do, then sketch the data those tasks require. That gives you enough structure to make a first schema without pretending you can predict every detail in advance.

Build one small end-to-end feature, such as displaying a record and filtering a set of records. You’ll learn whether the schema supports the actual interface, and can adjust it before too much code depends on it.

If planning the data is the part you enjoy, lean into it, but don’t try to design the entire database for every possible future feature. Write down the core entities, their relationships, and the important queries. Then put that design to work in a thin prototype.

For a reference site, questions like “How will users filter this?” and “Can one item have several categories?” matter more than guessing how much data you might eventually have. You can revise the schema as real needs become clearer.

Think of it as working in tandem, not choosing one side. The database and interface have a contract between them: what records exist, what can be changed, and what filters or sorts need to be supported.

You can make that contract explicit with a few example records and representative queries before building the full site. Then implement one useful slice at a time and change the schema when the use cases show a good reason.

Don’t spend weeks perfecting a schema before you’ve tested the basic workflow. A reasonable first design is enough. Build a simple page that reads from it, and make sure adding or updating data is manageable too.

For a personal project, the best plan is usually the one that gets a useful version running while keeping the data model understandable. You can optimize later if actual usage shows a performance problem.