Do you need a database or a library?

Notion's fundamental abstraction is the database. Everything in Notion is, at some level, structured data: pages with properties, entries in tables, items on boards. You define the schema (which properties, which types, which relations), you populate it with entries, and you create views that filter and sort the data according to your needs.

This is a powerful model for certain kinds of work. Project management, where tasks have defined states, owners, and deadlines. CRM, where contacts have structured attributes and deal stages. Inventory tracking, where items have quantities, locations, and categories. Any domain where the structure is known in advance and the data is highly regular benefits from the database model.

Most personal knowledge work is not like this.

How knowledge actually behaves

Your reading notes don't have a consistent schema. Some are three sentences. Some are three pages. Some reference other notes. Some stand alone. The properties that matter vary: a book note might need an author and a rating, while a research note needs a methodology and a finding, and a meeting note needs attendees and action items. Forcing all of these into a single database structure means either making the schema so generic that the properties are useless, or maintaining multiple databases with different schemas, which creates the maintenance overhead that drives Notion fatigue.

Your saved articles don't need to be categorised at capture time. You save them because they're interesting or relevant, and the context for why they matter often only becomes clear weeks later when you're working on something they connect to. A database requires you to classify at the moment of capture (which project? which topic? which status?). A library lets you capture now and find later, because the search works by meaning rather than by the categories you assigned.

Your ideas arrive in fragments: a phrase in a voice memo, a paragraph in a note, an annotation on a PDF, a message to yourself in email. These fragments don't have database properties. They have meaning, which connects them to other fragments in ways that a schema can't anticipate. A Zettelkasten or evergreen notes practice works with these fragments because the linking is conceptual rather than structural. A database imposes a structure that the fragments resist.

The library model

A library is organised differently from a database. In a library, you put things in and you find them when you need them. The filing can be minimal (a few broad categories) or absent (everything in one collection), because the retrieval is handled by search rather than by browse.

A well-run library has three properties that a database doesn't:

Capture is frictionless. You add something to the library without deciding its category, its properties, or its relationship to everything else. A web clip, a voice memo, a note, a PDF: each goes into the collection with minimal effort. The lower the capture friction, the more consistently you capture, and consistency is what makes the library valuable over time.

Retrieval works by meaning. You describe what you're looking for and the system finds it. Semantic search handles synonyms, related concepts, and conceptual queries that keyword search can't. You don't need to remember the exact words, the exact category, or the exact date. You need to know roughly what you're looking for, and the system does the rest.

Organisation is emergent. Rather than defining structure upfront and maintaining it manually, the library's organisation emerges from the content itself. Related items cluster. Tags are suggested. Connections surface. The structure serves the retrieval rather than the retrieval depending on the structure.

Which do you need?

If your primary need is tracking structured data with known properties (tasks, projects, contacts, inventory), a database serves you well and Notion is excellent at it.

If your primary need is capturing, connecting, and retrieving knowledge (notes, research, reading, ideas, reference material), a library serves you better because the knowledge doesn't have a consistent schema and the retrieval depends on meaning rather than on structure.

Most people who are frustrated with Notion are people who are using a database model for library-shaped work. They're defining schemas for things that don't have schemas, maintaining structures for things that don't need structures, and spending time on the architecture when they should be spending time on the thinking.

The library model is the one where you capture freely, search by meaning, and let the system handle the organisation. It's the model where the time goes to the work rather than to the infrastructure that's supposed to support it.

Frequently asked questions

Can't I use Notion as a library by ignoring the database features? You can, but Notion's search is keyword-based and doesn't search inside PDFs. Without semantic search and without content-level indexing, using Notion as a library means a lot of content you capture becomes unfindable as the collection grows. The library model depends on search quality, and Notion's search isn't built for it.

What about tools that offer both databases and libraries? Some tools provide structured views (like kanban boards and task lists) alongside unstructured content and semantic search. Fabric offers this: you can use structured views when they're useful (project tracking, task management) while the broader knowledge library handles everything else with AI organisation and semantic search.

Is a library just an unorganised pile of stuff? With keyword search, yes, it would be. With semantic search and smart organisation, it's a self-organising collection where everything is findable by meaning. The organisation exists, but it's handled by the system rather than by you.

Related reading: Your Notion workspace is a second job, The different types of knowledge, What is knowledge management, How to organise your digital life. Related pages: Fabric vs Notion, Search, Smart organization.