Design Workspace Search

Every Notion workspace grows into a pile of pages, and the way you get back to something you wrote three months ago is the search box. It looks like a plain feature until you remember what a Notion document is. A page is a block whose text lives scattered across a subtree of child blocks, each with its own id, type and properties. A database row is that same block primitive with typed columns hanging off it. So the moment you sit down to index a workspace, you are indexing a recursive tree of typed records. And you are doing it under a permission model where a person can see some branches of that tree and not others.

This is one of the reported system design shapes for a Notion loop, usually phrased as building full-text search across millions of blocks. Treat it as a real design, more than a quick add-on to the storage lesson. The interesting parts are not the parts that make it look like a generic search box. Three things are specific to Notion. What you treat as a searchable document when the text is spread across a block subtree. How you never leak a title from a page the viewer cannot open. And how a block a teammate edited two seconds ago shows up in your results without you querying the live database on every keystroke.

The Notion angle

A Notion search result is only correct if the viewer is allowed to see it, so permission-filtering is the spine of this design, not a filter you tack on at the end. Notion resolves access by walking up a block's parent pointer to the nearest place with an explicit sharing setting, inheriting from workspace to teamspace to page to subpage. That means two people running the identical query in the same workspace should get different result sets, because they can reach different branches of the tree.