DEV Community: Evgene

SQL-like Queries in FSRS Plugin for Obsidian

Evgene — Sat, 30 May 2026 21:38:10 +0000

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:

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).
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:

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

FSRS Plugin for Obsidian: Rust/WASM Architecture and Performance

Evgene — Sat, 30 May 2026 21:35:27 +0000

FSRS Plugin for Obsidian: Rust/WASM Architecture and Performance

A spaced repetition tool for Obsidian notes must use a modern algorithm and work locally with notes as-is (without rewriting them into flashcards).

Existing Obsidian plugins stop at the SM-2 algorithm circa 1987.

Alternative solutions exist "somewhere else" — outside free software, outside Markdown-first architecture — tied to the cloud or a proprietary format.

I wrote my own because I couldn't find a suitable one.

FSRS, a computational core in Rust compiled to WebAssembly.

This article covers: WebAssembly architecture, a custom parser, a lexer, and performance benchmarks. Every query runs in hundredths of a second. Blazingly fast 🦀

This is a technical article. For a step-by-step user guide, see the overview article.

Why a Fourth Spaced Repetition Plugin?

At the time of writing, three popular solutions exist in Obsidian: obsidian-spaced-repetition, obsidian-recall, and obsidian-review. All use SM-2 — an algorithm nearly 40 years old. It works, but requires roughly 30% more reviews than FSRS for the same retention level.

The main drawbacks of SM-2:

Same interval regardless of material difficulty
Doesn't handle breaks — resets progress after a gap
No concept of retrievability — the probability of recalling a card right now

FSRS is a step forward. But it wasn't in Obsidian. Until now.

How FSRS Works in a Nutshell

FSRS operates on a DSR model with three parameters:

Difficulty — how hard the material is. Range: 0–10
Stability — memory strength in days
Retrievability — probability of recalling the card right now

After each answer (Again / Hard / Good / Easy), the algorithm recalculates difficulty and stability. Retrievability changes continuously.

The algorithm uses 21 parameters, tuned by machine learning on millions of real reviews.

Architecture: Why Rust and WebAssembly

An Obsidian plugin is JavaScript. But FSRS requires precise floating-point calculations on every review.

I chose Rust for three reasons:

Performance — WASM runs orders of magnitude faster than JS on numerical computations
Ecosystem — the rs-fsrs crate from the open-spaced-repetition community, providing the reference FSRS implementation
Type safety — in Rust you can't accidentally mix up difficulty and stability

Separation of concerns:

TypeScript                  Rust/WASM
─────────                   ─────────
• Obsidian API              • FSRS computations
• UI / rendering            • SQL-like syntax parsing
• File system               • YAML/JSON parsing
• Plugin lifecycle          • Filtering and sorting
• Buttons, modals           • Card cache

TypeScript is a thin wrapper over the Obsidian API. All logic lives in WASM.

Performance: The WASM ⇆ JS Boundary

Minimizing Cross-Boundary Copying

Cache inside WASM — filtering and sorting happen right there in Rust. Only the result (20–200 rows) crosses the boundary, not all 10,000 cards.
Incremental updates — answering a card recalculates only one record.

metadataCache: Don't Read Files

The biggest speed gain comes from not reading files. Obsidian stores parsed frontmatter in metadataCache — an in-memory cache that updates on every note change.

The plugin checks for FSRS fields via metadataCache.getFileCache() — instant, in-memory access, no I/O. Out of 105,607 files, only those whose frontmatter already contains reviews are actually read.

For reference: the plugin's own parser processes 105k files in 16 seconds, filters out 100k, and processes 5k.

Obsidian spends ~20 minutes indexing 105k files,
and ~120 seconds on 5,000 freshly added cards.
So the fair comparison is 16 seconds for the plugin vs. 120 for Obsidian.
But Obsidian does it anyway — so it's more efficient to use the ready-made cache.

Numbers

FSRS calculation for all cards runs once during the initial
vault scan. After that, the cache lives in WASM — all subsequent
operations (table load, heatmap, single card update) work with
pre-computed data and don't depend on vault size.

Operation	Large vault (105k files, ~5,000 cards)	Small vault (710 files, 104 cards)
Initial scan (FSRS for all cards)	3.2 s	0.04 s
Table load (after cache)	0.07 s	0.04 s
Heatmap	0.02 s	0.01 s
Single card update	< 0.01 s	< 0.01 s

The difference between 5,000 and 100 cards after caching — 0.03 s. Large vault logs, Small vault logs with plugins

Every plugin action, after the initial calculation, runs in hundredths of a second.

The Bottleneck

3.2 seconds for initial load — that's the FSRS calculation for each of 5,000 cards. Runs only once.

States could be persisted to disk cache, but:

Syncing complexity between devices (on-disk cache can go stale)
5,000 cards / 3.2 seconds — acceptable for real-world use
After the first launch, subsequent plugin loads are instant — the cache is already in WASM

What's Wrong (About Trade-offs)

LIMIT in the current implementation doesn't short-circuit processing — to guarantee the first N rows by retrievability, all cards must still be evaluated.

A deliberate trade-off: a real user's vault rarely exceeds 5,000–10,000 entries; a full scan + sort takes 0.005–0.010 s.

WASM Cache Instead of Local State

The entire cache (HashMap<filePath, CachedCard>) lives inside WASM as a global variable. The plugin stores no state in TypeScript at all.

Why:

Single source of truth — no desync between JS state and WASM computations
Fast queries — filtering/sorting happen right where the data is
Incremental updates — targeted commands: "update this card" / "delete this one"

Where data lives. Review progress is stored directly in a note's YAML frontmatter:

---
reviews:
  - date: "2026-05-03T12:00:00Z"
    rating: 2
  - date: "2026-05-04T08:30:00Z"
    rating: 3
---

due, stability, difficulty, and state are not stored — the WASM core computes them on the fly from the review history.

SQL-like Language for Tables

The plugin's headline feature — selecting cards for review via an fsrs-table block.
You write a SQL-like query in a markdown note and get a live table
that auto-updates with every review.

Under the hood: a custom parser built from scratch — lexer → parser → AST → evaluator
in Rust/WASM. Supports SELECT, WHERE, ORDER BY, LIMIT,
and the date_format() function.

Full breakdown in a dedicated article:
SQL-like Queries in FSRS Plugin.

No Mocks as a Consequence of Architecture

Mocks aren't needed — not because they're "forbidden," but because there's nothing to mock.

TypeScript in the plugin is a thin wrapper over the Obsidian API. All logic is in Rust/WASM. Mocking Obsidian would mean checking whether the plugin closes a <div>, or whether it called vault.read() — trivial glue not worth testing. What's worth testing: the integration between your own TypeScript and your own WASM.

So tests are split into two levels:

Rust tests (184) — pure functions, isolated from the environment
TypeScript tests (86) — unit tests for pure functions and TS → WASM integration tests

Integration tests start and end with your own code: a raw string, a parameter, or a call on the input (TS) → parsing (WASM) → WASM cache query (WASM) → result (TS).

CI/CD: Build, Test, Release at the Push of a Button

A GitLab CI pipeline with seven stages:

check — cargo fmt, cargo clippy, cargo test
build-wasm — wasm-pack build
encode-wasm — embedding WASM as base64 for the bundle
test — TypeScript tests (vitest)
lint — tsc --noEmit + ESLint
build — final main.js build
release — automatic GitHub release

Current Status

The plugin is ready to use.

Tested on Ubuntu, Windows, and Android.

Available in the Obsidian community plugin catalog.

What's already done:

CI/CD that builds and publishes releases automatically
Transparent storage — all data in YAML frontmatter of your .md files
TS → WASM integration tests (raw SQL, no mocks)
Heatmap
Russian, English, and Chinese localization
SQL-like queries for table-based card selection

Planned:

Gather feedback
Polish the mobile interface

How to Install

Available in the Obsidian community plugin catalog.

Settings → Community plugins → Browse
Find FSRS → Install
Enable the plugin in Settings → Community plugins

Stack

TypeScript — Obsidian API, UI
Rust — computational core (WASM)
esbuild — JS bundle build
wasm-pack — WASM build
Vitest — TypeScript tests
GitLab CI/CD — pipeline

Links

Evgene Kopylov, 2026

FSRS for Obsidian: remember what matters

Evgene — Sat, 30 May 2026 21:29:32 +0000

FSRS for Obsidian: remember what matters

Obsidian is called a "second brain". But to truly become one, links alone aren't enough — you need memory.

I built a spaced repetition plugin powered by the modern FSRS algorithm. It remembers what you studied and when, how hard it was, and predicts your recall probability. All data stays in your .md files — nothing is sent to any server.

Why another repetition plugin?

Because you shouldn't have to fiddle with cards when your notes are already right there.

SM-2 vs FSRS

SM-2 repeats everything at the same intervals. Miss a week? Progress resets. You can calculate it on a napkin.

Problems with SM-2 in practice:

Same intervals for easy and hard material — you review what you know and what you don't at the same rate
Progress reset after a break — skipped a week? Start over.
No forgetting prediction — the plugin won't tell you that you're about to forget

FSRS solves all of this. At the same retention level, it requires roughly 30% fewer repetitions — and with FSRS-6 used in the plugin, the real-world difference is noticeably larger.

FSRS plugin vs other tools

Feature	Obsidian + FSRS (this plugin)	Anki + FSRS	RemNote + FSRS
Data format	✅ `.md`, your files	⚠️ SQLite, optional cloud	⚠️ Local or cloud by choice
Card context	✅ Full note, links, graph	⚠️ Snippets of text	✅ Note = card
Card creation	✅ Note = card	❌ Copy-paste, form	⚠️ Quick from rem
Algorithm	✅ FSRS	✅ FSRS	✅ FSRS
Privacy	✅ Fully offline	⚠️ Local, optional account	✅ Offline mode
Sync	✅ Not needed — sync your vault	✅ Free via AnkiWeb (optional)	❌ Pro subscription only
Open source	✅ Fully open	✅ Fully open	❌ Closed
Visuals & extras	✅ heatmap	✅ add-ons available	✅ built-in
Analytics	✅ SQL-like queries, filtered views	✅ Free, add-ons	⚠️ Basic free, advanced paid

How FSRS understands your memory

FSRS calculates three parameters for each card based on review history (date and rating):

Parameter	Meaning	How it changes
Difficulty (D)	How hard the material is	Stays nearly constant — a hard topic stays hard
Stability (S)	How firmly the memory is held, in days	Grows with each successful review
Retrievability (R)	Probability of recall right now	Falls every second after review

After each answer (Again / Hard / Good / Easy) the algorithm recalculates difficulty and stability. Retrievability decays on its own — when it drops below the threshold, the card appears in the review list.

The threshold is configurable: want 90% retention? You'll review more often. 80% is enough? Fewer reviews.

How it looks in Obsidian

Nothing but Obsidian is required. Install the plugin and go.

1. Add FSRS fields to a note

Open the note you want to turn into a card. Call up the command palette (Ctrl/Cmd+P) and run:

FSRS: ＋ Add FSRS fields to frontmatter

A reviews array will appear in the frontmatter — this is where the plugin stores review history. A review button is added right after the frontmatter:

---
reviews: []
---

```fsrs-review-button
```

In reading view, the code block becomes a button. Click it to see four rating options: Again, Hard, Good, Easy. No need to switch to edit mode.

You don't have to insert the button manually — the plugin adds it automatically when initializing a card. If you disable auto-add in settings, you can insert it via FSRS: □ Insert review button block.

The plugin records dates and ratings into the reviews field. After a couple of reviews, the frontmatter will look something like:

---
reviews:
  - date: "2025-03-15T12:00:00Z"
    rating: 2
  - date: "2025-03-17T08:00:00Z"
    rating: 3
---

The rating value: 0 = Again, 1 = Hard, 2 = Good, 3 = Easy.

2. Create a review table

In a separate note (e.g. your daily note), open the command palette and run:

FSRS: ⬒ Insert default fsrs-table

No SQL knowledge needed — the command inserts a ready-to-use block. It looks like this:

```fsrs-table
SELECT file as " ", difficulty as "D",
       stability as "S", retrievability as "R",
       date_format(due, '%Y-%m-%d') as "Next"
LIMIT 20
```

In reading view, the block becomes a table with all your cards, sorted by urgency — most forgotten first.

3. Review without leaving the table

This is the main workflow. Hover over a filename in the table — a popup appears with the note content and the review buttons inside it. Rate the card and move on to the next.

The entire review cycle stays in one window:

Open the note with the table
See which cards are due
Hover over a card — read the content
Click a rating — the card updates
Move to the next row

Later you can customize the query. Here are some practical examples:

Query	What it does	Why
`WHERE retrievability < 0.6`	Cards about to be forgotten	Review before it's too late
`WHERE state = "New"`	Cards with no reviews yet	See what you added today
`WHERE file = "Topic"`	A specific note (by filename without path or extension)	Check one card's status
`ORDER BY reps DESC`	Most-reviewed cards	See what you've practiced most

All available fields and conditions are in the user guide.

5. Review heatmap

To see your progress over the year — how many reviews per day — insert the block via FSRS: Insert heatmap fsrs-heatmap (Ctrl/Cmd+P) or create it manually:

```fsrs-heatmap
```

In reading view, a day-grid appears showing your activity.

Installation

The plugin is available in the Obsidian community catalog.

Open Settings → Community plugins → Browse
Search for FSRS
Click Install
Enable the plugin in Settings → Community plugins

What else

User guide — step-by-step instructions for all features
Technical article — architecture, Rust/WASM, performance
Repository on GitHub — source code

Evgene Kopylov, 2026

DEV Community: Evgene

SQL-like Queries in FSRS Plugin for Obsidian

SQL-like Queries in FSRS Plugin for Obsidian

From Simple Settings to an Embedded DB

What's Inside fsrs-table

Supported Features

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

How It's Implemented (Briefly)

Performance

Real-World Query Examples

Review what's about to be forgotten

Drill the hardest cards

Overdue cards (due in the past)

New cards only

Conclusion

Related Reading

FSRS Plugin for Obsidian: Rust/WASM Architecture and Performance

FSRS Plugin for Obsidian: Rust/WASM Architecture and Performance

Why a Fourth Spaced Repetition Plugin?

How FSRS Works in a Nutshell

Architecture: Why Rust and WebAssembly

Performance: The WASM ⇆ JS Boundary

Minimizing Cross-Boundary Copying

metadataCache: Don't Read Files

Numbers

The Bottleneck

What's Wrong (About Trade-offs)

WASM Cache Instead of Local State

SQL-like Language for Tables

No Mocks as a Consequence of Architecture

CI/CD: Build, Test, Release at the Push of a Button

Current Status

How to Install

Stack

Links

FSRS for Obsidian: remember what matters

FSRS for Obsidian: remember what matters

Why another repetition plugin?

SM-2 vs FSRS

FSRS plugin vs other tools

How FSRS understands your memory

How it looks in Obsidian

1. Add FSRS fields to a note

2. Create a review table

3. Review without leaving the table

5. Review heatmap

Installation

What else

What's Inside `fsrs-table`

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