July 2nd, 2024

Graph-Based Ceramics

The article explores managing ceramic glazes in a kiln and developing an app. It compares Firebase, Supabase, and Instant databases, highlighting Instant's efficiency in handling complex relational data for ceramic management.

Read original articleLink Icon
Graph-Based Ceramics

The article discusses the challenges of managing ceramic glazes and combinations in a kiln and the author's journey in developing an app to streamline this process. Initially considering Firebase for the app, the author ultimately opts for a graph-based database like Instant due to its ability to handle complex relational data more efficiently. The article delves into the technical aspects of data modeling using Firebase's Firestore, Supabase (PostgreSQL), and Instant, highlighting the advantages and limitations of each approach. While Postgres solves data modeling issues, Firebase offers features like optimistic updates, real-time subscriptions, and offline support, which are crucial for a smooth user experience. Instant, being a graph database, combines the speed of Firebase with the relational capabilities of Supabase, offering a simpler querying language (InstaQL) and straightforward data handling through transactions. The author concludes that Instant's graph-based approach provides a more intuitive and efficient solution for managing ceramic data compared to traditional SQL databases.

Link Icon 8 comments
By @alfor - 3 months
Cool, another computer nerd into ceramic and glazes!

Glazes is actually glass where you mix all kinds of powdered element from the periodic table and melt them at 1200C to hopefully get a result you like. A unusual kind of chemistry.

I am more interested in the glazes and the results he got than the crud app and the DB. Just read it in diagonal, but I don't see why a simple Django app wouldn't take care of this easily (with admin) and you use sqlite for local use case.

By @romwell - 3 months
What an excellent ad for SQLite, where you could do this with a simple schema:

    Table 1: <piece id> <combo id> <location>

    Table 2: <combo id> <glaze id> <priority>
That's.. it.

Location specifies where the combo is applied to the part; priority specifies ordering of the glaze layers (glazes whose order doesn't matter have the same priority).

The only thinking that needs to be done is understanding that you don't mix glazes and combinations in a single project, but a project has a set of combinations associated with it, some of which may only have one glaze.

Writing the requisite SELECT queries (getting all pieces that use a glaze, or vice versa) is left as an exercise to the reader (which, I hope, is straightforward - but the same can be said of the schema).

This article does a lot of mental gymnastics to avoid using a relational database to store relations. NoSQL has its places (e.g. sometimes, a KV store is a KV store), but this isn't it.

Sometimes I feel like the NoSQL hype did some collective damage to the way people think about data. But then again, I'm not a database architect, so what do I know.

By @ajkjk - 3 months
I would definitely use a simple relational model for this. Or probably in practice just download the whole dataset and do everything locally because it's going to be so small.

But I suppose this is an ad for the writer's graph database anyway.

By @zafka - 3 months
I suggest you check out clayart mailing list: https://lists.clayartforum.com/mailman/listinfo/clayart You can get great feedback from some of the best potters in the world. Also the authors of one of the definitive books on Cone 6 glazes hang out there.
By @simonw - 3 months
My partner does ceramics and she has an incredibly detailed Airtable database for this, it's truly beautiful to behold.
By @FrustratedMonky - 3 months
I would really like to see a visual of how these different treatments lead to different results. To see the 'graph', with the actual end results. I know at top of article there were some pictures, maybe I'm missing it and it is linked somewhere.
By @m3kw9 - 3 months
You would have been done with maybe 1/10 the code if you went with SwiftData and targeted ios17 as the base os as that is also a graphdb, you don’t really need a server for this type of app. Everything local would be good enough.
By @douglee650 - 3 months
I wonder if using Blender shader networks would be a good way to model this? Especially with procedural nodes, where interactions might be modeled.