I’m working on understanding how Notion structures its data model through their API. From what I can tell, Notion treats most content as blocks - pages are blocks that contain other blocks like text, images, lists, and more.
This makes me wonder if databases follow the same pattern. Are databases also just another type of block in Notion’s system?
I’m building a similar app and trying to figure out the best database structure. Should I set up my models like this:
- users
- workspaces
- blocks (pages, text, images, todos, etc)
- databases (separate table)
Or would it be better to treat databases as just another block type:
- users
- workspaces
- blocks (databases, pages, text, images, todos, etc)
Any insights on how Notion actually handles this would be really helpful for my project design.
I’ve worked with Notion’s API quite a bit - databases technically inherit from blocks but behave very differently in practice. You can query them through block endpoints, but they’ve got dedicated database endpoints with way more functionality. The main difference? Databases need schema info, property definitions, and view configs that regular blocks don’t have. I treat databases as specialized blocks architecturally, but you’ll need extra tables for the database-specific metadata. The unified block approach gives cleaner permissions and hierarchy management, which is huge when you’re scaling. Just heads up - be ready for extra complexity around database properties and filtering.
databases are blocks, but kinda unique. in my experience with Notion’s API, databases have their own type even tho they’re based on blocks. i think your second way is the right choice, but keep in mind they’ll need extra handling for props and relations that regular blocks lack.
Yes, databases are indeed considered blocks within Notion’s API framework. When you retrieve a database, it is delivered with a block_id, aligning with the behavior of other block types. However, databases possess their unique endpoints and additional metadata that standard blocks do not offer. I recommend adopting your second proposed structure—viewing databases as a specific type of block. This approach promotes clarity and facilitates scalability. In my experience, implementing a polymorphic blocks table that includes databases has streamlined maintenance. You can still manage database-specific details in dedicated tables while preserving the block hierarchy for enhanced navigation and permission management.