Notes / knowledge base, built on every verified stack.
Notes / knowledge-base: user-owned notebooks, free-form tags, and per-note read/write sharing.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Notes / knowledge base gives you
Access here is note-shaped, not notebook-shaped. notebooks has a single owner_id and no share table of its own; note_shares grants another user read or write on one note at a time, constrained by note_shares_permission_check to exactly read or write and deduplicated by note_shares_note_user_unique on (note_id, shared_with). That composite unique turns a grant into an upsert — promoting someone from read to write updates the existing row instead of stacking a second one — but it also means a whole notebook cannot be handed over in one statement: collaborating on twenty notes is twenty rows. Notes carry two identity columns that are easy to conflate. notebook_id points at the container, whose owner_id decides who the notebook belongs to; author_id points at whoever wrote the note.
They are independent foreign keys into user, so one notebook can accumulate notes written by different people and an authorship query never walks up to the container. body is nullable — a note is a title until someone writes into it — and is_archived is a plain boolean defaulting to false rather than a deleted_at timestamp, so archiving is reversible; since no partial index excludes them, archived notes still sit in idx_note_notebook and every notebook read filters them out in the predicate. Tags are free text with no tag table behind them: note_tags holds (note_id, tag) and note_tags_note_tag_unique rejects the same label twice on one note, so a note's tag list arrives already deduplicated.
The leading column of that unique is note_id, which makes the tags on this note cheap and leaves the reverse — every note carrying one label — as a scan. note_shares has the same asymmetry: its unique leads with note_id, so who can see this note is indexed while what has been shared with me is not. Both are one CREATE INDEX away; the schema simply does not presume you need them before you build the surface that asks.
Built for
idx_note_notebook on notes.notebook_id scans a single notebook, and the is_archived boolean splits live from archived in the same predicate rather than in a second table.
idx_notebook_owner on notebooks.owner_id drives the sidebar; owner_id cascades from user, so a deleted account takes its notebooks and their notes with it.
note_tags_note_tag_unique on (note_id, tag) leads with note_id for the read and rejects a repeated label on insert, so nothing downstream has to de-duplicate.
note_shares_note_user_unique on (note_id, shared_with) fetches a note's whole grant list from its leading column, and note_shares_permission_check pins each grant to read or write.
note_tags.note_id and note_shares.note_id both reference notes with ON DELETE CASCADE, and notes cascade from notebooks in turn, so one DELETE clears the note's labels and every share of it.
Why Notes / knowledge base, specifically
note_tags enforces a unique constraint on (note_id, tag), so duplicate tags per note are rejected at the DB level rather than in application code.
note_shares carries a CHECK constraint limiting permission to 'read' or 'write', and a composite unique on (note_id, shared_with) — one share row per user per note, updated in place rather than appended.