Hi @matthiscock, yes drafting potential phases is a good idea. As much as I'd like to have a tagging function in Outline, I'm not too sure that it could be considered a step towards a spreadsheet-like interface for relational tables linked to a data source like PostgreSQL.

Broadly speaking, maybe @tommoor could better highlight the main building blocks needed to create the foundation for such a feature.

Hi, thanks for your input. You’re right—if we were to focus solely on the term "database" it would only scratch the surface of what we’re trying to achieve. That’s why I emphasised the importance of a no-code RDBMS solution with ACID compliance.

Anyway, your post gives me a great opportunity to improve my original table 🙏 and expand on the different layers of structured data:

Structured data capability levels

(From unstructured text to industrial-grade RDBMS)

⭐ — Level 1: Plain markdown tables

Text-first cells with no schema.
Basic Markdown pipe syntax (|), no column types, sorting, or programmatic access.

⭐⭐ — Level 2: Rich text/block-based tables

Visual grids rendered via WYSIWYG editors (ProseMirror, TipTap).
Slash-command inserts (/), row/column resizing, usually no typed fields and definitely no table relations.

Outline is at this level.

⭐⭐⭐ — Level 3: Typed fields & one-way relations

UI-configurable columns/field types (text, number, date, select, checkbox).
Basic single-directional links (e.g., "link to page" or "record linking").

⭐⭐⭐⭐ — Level 4: Bidirectional relational tables

SQL-like relations (one-to-one, one-to-many, many-to-many), formula fields, rollups, joined views.
Unified database-kernel with synced views (table/board/calendar).

⭐⭐⭐⭐⭐ — Level 5: No-code/low-code RDBMS (ACID-compliant)

Full relational schema managed via GUI/API, built atop PostgreSQL/MySQL/MariaDB (data source).
Transactions, atomicity, and crash recovery baked into the data layer.
JOINs, triggers, stored procedures, and SQL query support.

NocoDB, Teable, Supabase are all at this level.

Key point

Between level 1 and 4—the data logic lives in the application layer (proprietary formats, limited scalability) and relations are emulated.
At level 5—data logic lives in a database layer (standard SQL, ACID) and no-code abstractions sit atop battle-tested RDBMS engines. This also enables compliance with GDPR, SOC2, or HIPAA via granular permissions/encryption.

Does this make sense?

Some parts are too technical for me 😆. The different levels seems to be logical with a nice progression in technical complexity. I'm not a dev, so I can't say much more.

Hi @Jasdent, as of today, Docmost would be at Level 2.

@almereyda I see your point, but embeds are essentially a duct-tape solution.

The goal here is to elevate your wiki/KB into a truly structured, relational layer for knowledge — one that’s inherently searchable, linkable, and queryable from within Outline itself.

Embedding Grist misses the mark because:

• Searchability: Data embedded through iframes remains invisible to Outline’s search and knowledge graph.
• Structured authoring: You lose the native ability to create, edit, and relate data within your documents.
• Core features compromised: Permissions, backlinks, and versioning get sidelined.
• UX: Switching between separate ecosystems disrupts workflow.

...just to mention a few.

All of which assumes, that it is within the desired scope of Outline intending to be a structured knowledge graph for rich documents, blocks and properties.

All of which assumes, that it is within the desired scope of Outline intending to be a structured knowledge graph for rich documents, blocks and properties.

I believe the opposite.
It is the desired scope of many Outline's competitors, Outline's users... but unfortunately I'm not so sure it is the desired scope of the Outline's owners.

I like the distinction you draw here, encompassing the community in your understanding of the ownership model of Outline.