This content originally appeared on DEV Community and was authored by Evgene
SQL-like Queries in FSRS Plugin for Obsidian
Spaced repetition in Obsidian usually works as "show all cards with due earlier than today." That's enough for simple cases, but once you have hundreds of notes, you want to filter, sort, and select.
My FSRS plugin now has a query language resembling SQL. It turns a markdown block into a live table that updates with every review.
```fsrs-table
SELECT file as "Note",
r as "Retrievability",
date_format(due, '%d.%m.%Y') as "Due"
WHERE r < 0.7
ORDER BY r ASC
LIMIT 20
```
→ the table shows the 20 most "forgotten" cards, sorted by retrieval probability.
From Simple Settings to an Embedded DB
Initially I planned to offer table settings using standard SQL syntax. But pretty quickly the syntax became a real query language, and the implementation itself — an embedded lightweight DB.
High-level test coverage in TypeScript made it easy to iterate on functionality located in the WASM module via an AI agent.
When faced with dual-language testing (TypeScript + Rust), the artificial intelligence prefers to do the job properly rather than fake it.
After implementing the lexer → parser → AST → evaluator pipeline for numeric values, I extended it to strings, added filtering via WHERE, then functions.
Extending the syntax or adding a function came down to a single request to the agent — and a feasibility check.
What's Inside fsrs-table
Supported Features
-
SELECT— choose fields, rename viaAS. -
WHERE— conditions with=,!=,<,>,<=,>=,AND,OR. -
ORDER BY— sort ascending (ASC) or descending (DESC). -
LIMIT— cap the number of rows. -
date_format()— convert theduedate to any text format.
Available fields:
| Field (alias) | Type | Description |
|---|---|---|
file |
string | path to the note |
due |
date | next review date |
stability (s) |
number | stability in days |
difficulty (d) |
number | difficulty |
retrievability (r) |
number | probability of recall (0…1) |
reps |
number | total number of reviews |
state |
string | New, Learning, Review, or Relearning |
elapsed |
number | days since last review |
scheduled |
number | scheduled interval in days |
What fsrs-table Can't Do (and Shouldn't)
- Subqueries,
JOIN, aggregations (COUNT,SUM…). - Data modification (
INSERT,UPDATE,DELETE). -
LIMITdoesn't short-circuit processing (to guarantee the first N rows by sort order, all cards must be evaluated).
This is not a database — it's a filter + sort over a cached set of cards.
How It's Implemented (Briefly)
All query processing happens inside Rust/WASM:
-
Lexer turns the query string into tokens (
SELECT,WHERE,LIMIT, identifiers, operators). - Parser builds an AST (abstract syntax tree) respecting operator precedence.
- Evaluator walks the AST for each card and checks the condition.
// simplified: WHERE clause AST
pub enum Expression {
Comparison {
field: String,
operator: ComparisonOp,
value: Value,
},
Logical {
left: Box<Expression>,
operator: LogicalOp, // AND or OR
right: Box<Expression>,
},
}
The parser is hand-written (not nom/pest) to keep full control over error messages. On an invalid query, the plugin shows a readable message: "Unknown field: retriv".
Why not SQLite?
SQLite would require WASM compilation (maybe possible) and an extra synchronization layer. My implementation is lighter, needs no external dependencies, and works exclusively with data already loaded in memory.
Performance
The card cache lives inside WASM. On the first vault scan, the plugin computes stability, difficulty, due, and retrievability for each card. Subsequent queries work off this cache.
On a vault with 5,000 cards, end-to-end from UI action to displayed table:
- Full scan + condition evaluation for all cards takes 0.07 s.
- Sorting by
r— another 0.02 s. -
LIMITadds no gain, but 0.07 s is imperceptible to the user anyway.
All fields (stability, difficulty, retrievability) are computed on the fly from review history (stored in YAML frontmatter). Each answer recalculates only one card — cost < 0.01 s.
Real-World Query Examples
Review what's about to be forgotten
SELECT file, r as "Probability", date_format(due, '%d.%m')
WHERE r >= 0.3 AND r <= 0.7
ORDER BY r ASC
LIMIT 15
Drill the hardest cards
SELECT file, d as "Difficulty", s as "Stability (days)"
WHERE d > 5.0 AND state = "Review"
ORDER BY d DESC
Overdue cards (due in the past)
SELECT file, date_format(due, '%d.%m.%Y')
WHERE due < '2026-06-01_00:00'
ORDER BY due ASC
New cards only
SELECT file, reps
WHERE state = "New"
Conclusion
The realization that a table configuration method had turned into a full-fledged embedded database didn't come right away. Which suggests that's how the first DBs came to be — out of a need to solve simple practical problems.
The plugin is already available in the Obsidian community catalog. Install it, try it out, and write your own queries.
Or clone the plugin repository and check if you really can extend the SQL functionality with a single prompt to an agent.
Related Reading
- FSRS for Obsidian: Remember Everything — why the plugin exists and how it works
- FSRS Plugin: Rust/WASM Architecture and Performance — technical deep-dive into the architecture
Evgene Kopylov, 2026
This content originally appeared on DEV Community and was authored by Evgene
Evgene | Sciencx (2026-05-30T21:38:10+00:00) SQL-like Queries in FSRS Plugin for Obsidian. Retrieved from https://www.scien.cx/2026/05/30/sql-like-queries-in-fsrs-plugin-for-obsidian/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.