Designing a relational schema for ceramic glaze development
My role
Designer and builder
The working team
Solo project
Project duration
Ongoing
In ceramics, developing glaze recipes from raw materials involves managing a highly volatile, multi-variable chemical system. Variables such as chemical oxide composition (silica, alumina, and fluxes), suspension density, application thickness, and firing kiln atmospheres interact to dictate the final physical outcome.
While undertaking a self-directed research project at a ceramic production studio in Melbourne, I began formulating custom glazes from first principles. As my empirical testing grew to encompass over a hundred test tiles across distinct chemical bases, I encountered a massive unstructured data sprawl problem. Tracking formulas in spreadsheets, studio mixing checklists, and disjointed photo logs made it impossible to map the lineage, intent, and historical dependencies of my experiments. To solve this, I designed and built an end-to-end glaze experiment tracking application, Glaze Trails.
Discovery: Deconstructing non-linear lineage & data boundaries
Existing market solutions for glaze calculation typically treat a recipe as a static, isolated, one-off formulation. However, this completely misrepresents a glaze chemist's mental model. In practice, a glaze chemist never works on a single recipe in isolation – they systematically run controlled batches where they mutate one or two variables at a time to isolate direction. They then take the most promising data state and split it into a new branch of refinement.
Through a comprehensive audit of my own material workflows, I mapped out two core data streams that needed to be bound together:
The discrete variables (the state): the explicit recipe ingredients, raw chemical components, physical mixture viscosity, clay body substrate, and specific firing environment.
The relational lineage (the tree): the exact historical stream of thought and dependent relationships linking a brand-new test back to its parental jumping-off point.
Logic design: Modeling hierarchical relational taxonomies
To translate the non-linear reality of chemical experimentation into clean database logic, I designed a relational schema built on three distinct hierarchical tiers:
Lines (the parent class): Distinct, parallel glaze methodologies with fundamentally different chemical structures (e.g. crystalline, matte, or gloss)
Series (the logical branch): A grouped batch of concurrent recipes tested against each other (e.g. a series of glazes with zinc content increasing by 1% increments)
Recipes (the data node): The precise individual recipe containing exact weights, application metadata, and resulting oxide target metrics
When a specific recipe yields a promising outcome, the user can start a new series with the promising recipe as a base, and a foreign-key link pointing back to that parent recipe node.
Furthermore, I built the application's underlying data logic to convert raw material weights directly into a normalised Unity Molecular Formula (UMF) matrix. By transforming raw ingredients into chemical composition ratios, the interface allows users to compare separate recipes side-by-side, even if the materials vary.
Execution: End-to-end computational deployment
Operating as the sole architect and full-stack builder, I moved rapidly from structural concept to a functional, studio-tested tool:
Prototyping: leveraging Bolt to rapidly validate user flow layouts and mental models.
Production development: migrating the application into Cursor to refine the frontend logic and build code-level precision.
Backend & infrastructure: designing a relational Postgres schema on Supabase to preserve the cascading parent-child lineage of the lines, series, and recipes.
Deployment: hosting the environment via GitHub and Vercel for live, in-studio logging on mobile devices while managing hot kilns.
