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 via AS.


• 
  WHERE — conditions with =, !=, <, >, <=, >=, AND, OR.


• 
  ORDER BY — sort ascending (ASC) or descending (DESC).


• 
  LIMIT — cap the number of rows.


• 
  date_format() — convert the due date to any text format.

Available fields:

What fsrs-table Can't Do (and Shouldn't)

• Subqueries, JOIN, aggregations (COUNT, SUM…).


• Data modification (INSERT, UPDATE, DELETE).


• 
  LIMIT doesn'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:

1. 
   Lexer turns the query string into tokens (SELECT, WHERE, LIMIT, identifiers, operators).


2. 
   Parser builds an AST (abstract syntax tree) respecting operator precedence.


3. 
   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.


• 
  LIMIT adds 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