The Architectural Divide betweenTrilium and Obsidian
Software tools often promise revolutionary workflows for knowledge management. Every few months, a new app claims to solve organization once and for all. Trilium Notes is one such tool. It promises deep hierarchical nesting, rich note types, and programmable automation. A Google promoted article pushed Trilium on my timeline. It was written in a tempting way, but it turned out to be an overstatement.
At first glance, Trilium mimics Obsidian. It presents a familiar interface with sidebars, editor panes, links, and graph views. But surface appearances can be deceiving. Behind the interface lies an architectural philosophy that differs fundamentally from plain text writing tools.
Database vs. Plain Text
The core difference between Trilium and Obsidian rests in data storage. Trilium is a web application wrapped in an Electron container. It stores notes as rows inside a local SQLite database.
Obsidian takes the opposite path. It operates directly on plain Markdown files stored on a local disk. It means the files can be edited any time anywhere on any OS with a tiny text editor.
This distinction dictates the long-term relationship between the content creator and the content. Files on a filesystem belong to the user. Database records belong to the database application.
The Missing FileSystem and Import Friction
A real test for any note-taking tool is data portability. Migrating an existing knowledge base into Trilium reveals immediate friction.
For example, attempting to import an old research vault saved as a tar.gz archive fails. Trilium cannot unpack or digest structured file archives directly. Its web interface expects specific formats or uncompressed manual entries. The archive becomes unusable inside the app.
This creates an environment similar to Apple's iOS ecosystem. iOS hides the file system behind application boundaries. Trilium abstracts away the file system in favor of database keys.
When notes live inside a SQLite database, standard system utilities become useless. You cannot run grep to search text across files. You cannot use cat, rsync, or standard backup tools easily. Your knowledge remains trapped inside a proprietary database structure.
Deprecated SQL Web Architecture
Modern web design has shifted away from heavy database dependency. Many creators have intentionally removed SQL databases from personal websites, such as sandeepbhalla.online.
Databases introduce maintenance overhead, security vulnerabilities, and long-term bit rot. Moving to static file generators eliminates those headaches.
Re-introducing a SQL database to manage personal text notes makes little sense. It restores the exact complexity that static file systems were designed to eliminate. Plain text files do not rot, break schemas, or require database migrations.
Note Cloning vs. Linking
Trilium emphasizes note cloning as a primary feature. Cloning allows a single note to appear in multiple tree locations without duplication.
In practice, bidirectional linking already solved this problem. In Obsidian, inserting a double-bracket link ([[Note Name]]) connects ideas across any folder structure instantly.
Obsidian also handles folder hierarchies like a native operating system file explorer. You can rename, drag, drop, and nest folders directly on disk. The tree view in Obsidian reflects the real file system without database abstractions.
The Historical Web Curation by WordPress
In its early years, WordPress featured a bookmarklet called "Press This." It allowed users to capture web pages, clip snippets, and append thoughts quickly.
Trilium fits a very similar role for private web archiving. It features a web clipper and rich note types for canvas drawings and code blocks.
This functionality serves specific user roles well. A public relations manager saving dozens of press releases daily needs structured web clipping. A media researcher building a categorized news archive benefits from database attributes.
Maintenance Mode and the Community Fork
In January 2024, the original creator (zadam) announced that Trilium was entering maintenance mode. The GitHub repository (zadam/trilium) remains frozen in time. No new features are planned. Only critical bug fixes will be released. What began as a single-developer effort eventually ran out of steam.
In early 2024, community members led by Elian Doran forked the repository. They created TriliumNext to prevent the project from fading into memory. The team shipped its first stable release later that year. They actively maintain nightly builds, Helm deployment charts, and updated documentation. The team also plans to rebrand back to Trilium Notes with permission from zadam.
While the community stepped up to keep Trilium alive, this transition introduces new risks for users. Relying on community maintainers differs fundamentally from dedicated development. With the original architect gone, institutional knowledge becomes diluted. A community-driven roadmap can lead to slower decision making and feature bloat.
This development history explains the friction encountered during real-world testing. Broken imports, missing documentation, and awkward interfaces stem from original technical debt. TriliumNext addresses project sustainability, but it inherits the underlying design. The application remains a SQLite database wrapped inside an Electron container.
Ultimately, the fork repairs project longevity rather than its core design. For content creation, it remains the wrong tool. Writers choosing software today face two distinct risk profiles. Obsidian is backed by a dedicated company with over fifty employees and a clear roadmap. TriliumNext remains a volunteer-maintained fork of a project the original author walked away from.
That risk profile alone favors Obsidian, even before evaluating database lock-in.
Writers vs. Curators
Content curation and original writing require different tools. Content managers curate external information in Trilium. Writers draft original text in Obsidian.
Drafting long-form prose requires low friction and distraction-free environments. When Obsidian output or export functions seem limited, community plugins fill the gap. Plugins like Pandoc or Enhancing Export handle complex publishing formats smoothly. Static site tools like Quartz publish vaults directly to the web.
On top of that, Python libraries provide endless possibilities to manipulate text files and generate desired output.
Content Ownership Wins
Testing alternative software clarifies what truly matters in a writing workflow. Features like nested trees and embedded database scripts cannot replace plain text ownership.
Trilium is not badly built software, but it is mispositioned for writers. Plain Markdown files remain readable, portable, and future-proof. Trilium may be suitable for on-the-go content consumers or web clippers consuming knowledge.
Obsidian respects file transparency and user control. For content creation like writing, drafting, and thinking, Obsidian remains the superior choice.
Why Obsidian Wins
| Feature | Obsidian | Trilium |
|---|---|---|
| Data format | Plain Markdown files | SQLite database |
| Portability | Universal, future-proof | Locked in |
| Import/Export | Drag and drop | Broken or convoluted |
| Sync | Your choice (iCloud, Dropbox, Git, Obsidian Sync) | Self-hosted or manual |
| Mobile | Native apps | Web interface |
| Community | Massive, active | Small, uncertain |
Obsidian's "your data is yours" is actually true because your data is just files. Trilium's version of the same claim is marketing. Your data is yours if you can figure out how to extract it from their database.
Leave a Response