Les Bases les secrets de cette grande nouveauté dans Obsidian, tutoriel Obsidian

TL;DR

Obsidian Databases is a core plugin available starting with Obsidian 1.9 and is built around property-based queries.

Briefing Cornell Notes

Briefing

Obsidian’s new core “Databases” plugin turns collections of notes into queryable tables—then lets those same results appear in multiple views (table, cards, and filtered “simple” views) that can be embedded inside other notes. The practical payoff is speed: properties update automatically across the database, new entries can be created directly from the filtered results, and the layout can shift without rebuilding the underlying data model.

The tutorial frames Databases as a core plugin available starting with Obsidian 1.9. Once enabled under Core Plugins, it supports creating a database via a query interface. The example builds a “movie list” database, where each movie note contains structured fields using Obsidian properties (the modern replacement for YAML/Front Matter). Properties include types like number, list, date, time, checkbox, and text—plus tags. The key design choice is that the database logic relies on properties, enabling consistent filtering and sorting.

After creating the database, the workflow centers on filters. The example shows filtering by a property named “type” (e.g., selecting only items where type starts/ends/contains “film”), with additional filter options such as file metadata (path, folder, extension, creation date, size) and property conditions (is, is empty, contains any of the following values, etc.). When the filter matches, the database immediately populates with existing notes—thanks to Obsidian’s background indexing.

The database then becomes editable in-place. Fields can be added as columns (e.g., actors, rating), reordered, renamed, or removed from the display. Editing a property updates the underlying note automatically. A standout moment: when a new movie note is created while the database is filtered to “film,” the new note is created and prefilled with the property values implied by the query (and later updates propagate back into the table). This behavior mirrors the “Notion-like” experience of editing directly inside a table while keeping the source as plain text notes.

Views add another layer. The same database can switch from a table view to card views, including image-backed cards. The tutorial demonstrates card rendering options like “cover” vs “contain,” and filtering card results by property values (e.g., only movies of type film, or only movies featuring a specific actor). Renaming a view affects embedded links, so the tutorial warns that transclusion-style embeds should reference the correct view name.

Finally, the database can be embedded into a dedicated note (e.g., “my cinematheque”) using Obsidian’s embed syntax with the database identifier plus a view selector. The tutorial also shows a more advanced approach: copying the database code directly into another note to create a “disconnected” snapshot that won’t break when the original view names change—though it’s described as less obvious and requiring care.

Overall, the database system is presented as a fast, property-first alternative to older DataView-style workflows: queryable, multi-view, and tightly integrated with note properties, links, and automatic updates—while still leaving room for users to decide when DataView remains the better fit.

Cornell Notes

Obsidian 1.9 introduces a core “Databases” plugin that builds queryable collections of notes using properties. In the movie-list example, filters target property values (like type=film) and the database populates instantly via indexing. Results can be edited directly in a table or switched into card views (including image cards with cover/contain behavior), and property changes update the underlying notes automatically. Databases can be embedded into other notes with a view selector, so a single database can appear in different layouts across a workspace. The tutorial emphasizes a property-first approach and warns that renaming views can break embedded references.

Why does the tutorial insist on using properties instead of relying on plain text fields?

Because database queries, filters, sorting, and inline editing all key off properties. Properties are structured fields attached to each note (the modern alternative to YAML/Front Matter). In the movie example, “type” is a property used to filter results to only films, and properties like “actors” and “rating” become columns or card fields. When a new note is created under a filtered database, the database can prefill property values implied by the query, and later edits update the note automatically.

How do filters work in Obsidian Databases, and what kinds of conditions are available?

Filters combine file-level metadata and property-level logic. The tutorial lists options such as filtering by file name, path, folder, extension, creation date, and size, plus property conditions like “is,” “is empty,” “starts with,” “ends with,” “contains,” and “contains any of the following values.” In practice, selecting type=film immediately narrows the database to movie notes whose “type” property matches the chosen condition.

What makes the editing experience “Notion-like,” and what happens when a new item is created inside a filtered database?

The database renders results in a table (or cards) where fields can be added, reordered, renamed, and edited inline. When the database is filtered to type=film, creating a new entry in that view produces a new note and automatically applies the property values implied by the query. Later, when the database view is refreshed, updated property values (like ratings or actors) appear without manually reopening each note.

How do views change the presentation without changing the underlying data?

Views are alternate representations of the same database query results. The tutorial switches between a table view and card views, including image-backed cards. It also creates a “simple view” with additional per-view filtering (e.g., only movies where actor contains Louis de Funès), while the base filter (type=film) still applies. Renaming view names can affect embedded links, so view identity matters for transclusion-style embeds.

How can a database be embedded into another note, and why does the view selector matter?

Embedding uses Obsidian’s embed syntax with the database identifier and a view selector (the tutorial references using the database name plus a hash and the view name, similar to chapter-style integration). The embedded result can default to a specific view (like table), but the view selector can force card display permanently. If a view is renamed, the embed may not update correctly, so the tutorial recommends careful renaming or duplicating views rather than changing names casually.

What’s the difference between embedding a database and copying its code into a note?

Embedding keeps a live reference to the database and view, so renames can break the display. Copying the database code into another note creates a more independent snapshot: the tutorial describes it as “disconnected,” meaning the copied view can remain stable even if the original database’s view names change. The tradeoff is that it’s more complex and requires caution because mistakes can force rebuilding the database.

Review Questions

When you filter a database by a property like “type,” what property values must exist in the underlying notes for the database to populate correctly?
How would you design two views for the same database—one showing all films and another showing only films featuring a specific actor—without duplicating the database?
What risks arise if you rename a view that is already embedded elsewhere, and what safer alternatives does the tutorial suggest?

Key Points

1
Obsidian Databases is a core plugin available starting with Obsidian 1.9 and is built around property-based queries.
2
Properties (structured fields) are the foundation for filtering, sorting, and inline editing inside database tables and cards.
3
Creating or editing notes through a filtered database can automatically apply and update property values across the database results.
4
A single database can have multiple views (table, cards, and custom filtered views) that change presentation without changing the underlying notes.
5
Embedded database displays depend on the correct view selector; renaming views can break or desynchronize embeds.
6
Card views support image rendering options like cover vs contain, and image fields can be populated via external links as well as internal assets.
7
For more stability, copying the database code into another note can create a disconnected snapshot, but it’s more advanced and requires care.

Highlights

Databases populate instantly because Obsidian indexes notes in the background, so queries reflect existing notes as soon as the database is created.

Inline edits inside the database update the underlying note properties automatically—new entries created under a filter can be prefilled by the query conditions.

Card views can render images with “cover” or “contain,” and the image field can point to an external URL, not only an imported asset.

Embedded database output can be forced to a specific view (e.g., cards) using embed syntax with a view selector, but view renames can cause stale embeds.

Copying database code into another note can decouple the display from the original database, reducing breakage at the cost of complexity.

Topics

Obsidian Databases
Properties and Filtering
Views (Table and Cards)
Embedding Databases
External Image Links