Firestore Schema Design for Notion-Style Modules

How can I set up a Firestore schema to support recursive, modular blocks like Notion? Is it better to reference other blocks or use denormalized data?

hey, i lean more towards referencing blocks since its easier to update them recurively, but denormalised data can speed up reads. id choose based on what matters more in ur use case, speed or maintainabilty.

Based on my experience developing similar applications, I approached the problem by initially modeling the data with references to preserve the flexibility of recursive updates. I then strategically denormalized certain frequently accessed properties to optimize read speeds, ensuring that changes did not require too many external lookups. This hybrid method allowed me to maintain a balance between ease of maintenance and performance improvements. Ultimately, the optimal design was achieved by analyzing the operations in depth and testing rough prototypes, which helped in fine-tuning the balance between referencing and partial denormalization.

In my experience developing modular applications with Firestore, I found that using a hybrid approach works best. I initially relied heavily on references for recursive blocks, which allowed for greater control during updates. However, in scenarios where fast rendering of complex modules was necessary, denormalized data helped reduce read times significantly. Over time, I learned that the decision can shift depending on the specific operations being performed most frequently. Balancing both approaches, such as storing key metadata within parent documents and linking to full block content, has proven to be a robust solution, optimizing both performance and maintainability.