Performance

In short

• Sync (the everyday write): one changed note pushes in tens of milliseconds even on a 10 000-note vault; the first full import of 10 000 notes takes ~14 s on one core.
• Serving (the read hot path): a single small server (Hetzner cpx32, 4 vCPU) serves ~4 000 real documentation pages per second at 100 % success with a p99 of ~30 ms.
• Memory: ~80 MB per 100 notes, ~1 GB per 10 000.
• Anonymous page cache: a €6.49/month shared box (Hetzner cx23, 2 vCPU) sustains ~8 500 req/s of gzipped pages for 10 continuous minutes: 0 errors, 0 % CPU steal, ≈ €0.0003 per million requests.

Getting an honest serving number turned out to be surprisingly hard — three measurement traps, each costing roughly 2×:

1. Dev mode recomputes every asset's hash on each request (~2× slower) → benchmark with DEV=false.
2. Load generator on the same box steals CPU from the server (~2× slower) → run it from a separate machine.
3. Cold cache / a single URL flatters the result → hit many real pages with a warmed cache.

Our naïve first attempt was ~4× too pessimistic. The numbers below are after controlling for all three. Read on for the detail and the charts.

How fast is a vault sync, and how big can your vault get before you feel it? We measured the pushNotes mutation — the call the Obsidian plugin and the CLI make on every sync — on vaults of 10 to 10 000 notes.

The charts below are live datachart blocks reading the raw benchmark CSV from this vault — the same feature you can use for your own data.

Method

• Each run starts a fresh server with an empty SQLite database, pinned to 1 or 4 CPU cores (taskset + GOMAXPROCS).
• Synthetic notes of ~500 bytes: frontmatter, headings, a wikilink, a list, a code block.
• Initial push — all N notes in one pushNotes call (one write transaction).
• 1 note — a typical small sync: one changed note pushed into a vault of N notes (median of 3).
• 10% of vault — a batch sync: N/10 changed notes in one push (median of 3).
• Memory is the server's resident set size (RSS) after the run; peak from /proc.
• Benchmark script: scripts/bench-pushnotes.sh in the repository.

Important context: while a push is being processed, the server holds the database write lock — other writers (background jobs, other pushes) wait in line. So "push time" here is also "how long the database is locked".

Initial push: whole vault in one call

Scaling is close to linear: ~1.2 s for 1 000 notes on one core, ~14 s for 10 000. Four cores cut that roughly in half: note rendering parallelizes but the database writes do not.

Incremental sync: the everyday case

This is what you feel day to day: you edit a note, the plugin pushes it. Even at 10 000 notes a single-note push takes ~0.4 s on one core and ~0.2 s on four. The renderer caches unchanged notes, so the cost grows with vault size (re-indexing), not with how much you changed — pushing 1 000 changed notes (10% of a 10 000-note vault) takes ~2.3 s on one core, far from 1 000 × the single-note cost.

Memory

The server keeps rendered notes in memory: ~80 MB for a hundred notes, ~180 MB for a thousand, ~1 GB for ten thousand. Plan your hosting accordingly — a 1 GB VPS comfortably serves vaults up to a few thousand notes.

Vector search memory

Enabling vector search (semantic similarity, powered by an embedding model like bge-m3) builds an in-memory index alongside the note cache. The index stores one embedding vector per note — bge-m3 produces 1024-dimensional float32 vectors, so each note costs 4 KB.

At small vault sizes the vector index is invisible (40 KB at 10 notes). It becomes significant at 1 000+ notes: ~30–45 MB extra. At 10 000 notes it adds ~40 MB on top of the base note cache — consistent with the theoretical 1 024 dims × 4 bytes × N notes.

Raw numbers

Measured 2026-06-11 on a 12-core ARM64 dev machine restricted with taskset, SQLite in WAL mode, single server process. Your absolute numbers will differ; the shape of the curves will not.

Why page rendering is this fast

The numbers above are for write operations. Page reads are a different story: p50 response time is 3–6 ms at any vault size, even under 10 concurrent users.

This is not an accident; it is an architectural choice. trip2g sits somewhere between a static site generator and a traditional CMS:

• Static generator (Gatsby, Hugo, Eleventy): builds HTML files to disk on deploy. Reads are instant because they're just file serving. But every content change requires a full rebuild — minutes for large sites, no live editing.
• Traditional CMS (WordPress, Ghost): renders every page on request — queries the database, fetches relations, runs templates. Flexible and live, but every reader hits the database.
• trip2g: renders HTML on write (during pushNotes) and stores the result in memory. Reads serve that pre-rendered HTML directly from a hash map — no database, no template engine on the hot path. The cost of rendering is paid once per content change, shared across all readers.

Keeping thousands of rendered pages in RAM turns out to be surprisingly cheap. A synthetic 500-byte note renders to ~800 bytes of HTML; 10 000 notes is roughly 8 MB of content. The rest of the ~1 GB RSS at that scale is Go runtime, SQLite WAL buffers, and search indexes — not the page cache. A $5/month VPS with 1 GB of RAM comfortably serves vaults of several thousand notes without touching the disk on reads.

There is still room to go further — the current architecture renders notes individually and assembles the final page (layout, injections) on each request. Pre-rendering complete pages would push latency even lower. But even without that, trip2g is already orders of magnitude faster than traditional database-backed CMS platforms on equivalent hardware.

How small a box can run it

We deployed trip2g on a range of cheap VMs and load-tested each from a separate machine (so the generator never steals the server's CPU), in production mode (DEV=false):

*Its single core holds ~500 rps of the / page (~43 KB) at 100 % with p99 < 50 ms; the knee is ~600–700 rps and past ~900 latency falls apart. Measured with the generator in the same US-East area (~23 ms away) — a first run with the generator in Germany showed a misleading "1 000 rps", but that 86 ms transatlantic link just throttled the generator so the droplet never got pushed. Prices are provider list rates.

Measurement note: these box-comparison numbers predate the 2026-06-29 page cache, so they show throughput without it. Within the table, the Hetzner rows were measured after the earlier write-path optimizations and the DigitalOcean row before them. For page-cache throughput on comparable hardware, see the section below.

Two findings matter more than the raw rates.

A deploy drops nothing. Restarting the service under live traffic — systemctl restart while requests were firing — dropped zero connections on both the 2-core Hetzner node and the $4 droplet (20 000 / 20 000 and 12 000 / 12 000 requests answered 200, no refusals). The listening socket stays open across the restart via systemd socket activation, so in-flight requests wait in the kernel queue for a few hundred milliseconds instead of being refused. One server, no load balancer, no downtime — see zerodowntime.

No object storage needed. With the local file-storage backend (--storage-backend=local), trip2g keeps assets and backups on the server's own disk — no MinIO, no S3. It booted on the $4 droplet using ~57 MB of RAM. The cheapest VM you can rent is enough to run a real site.

What this means for you

• Vaults up to ~1 000 notes: everything is instant — syncs are tens of milliseconds.
• ~10 000 notes on a small server: everyday syncs are still sub-second, but the first push of the whole vault takes ~14 s on one core. During that window the database is locked for other writers; on very large vaults prefer an initial import during quiet hours.
• More cores help rendering, not locking: a 4-core server halves big-push times. The lock is held for the whole push either way, so many concurrent writers gain less than the raw numbers suggest.

Anonymous page cache: 8 500 req/s on a €6.49/month box

The note-cache architecture above pre-renders HTML and holds it in memory, but per-request gzip and a handful of database lookups remain on the hot path. Both costs are now also eliminated for anonymous readers by a second layer: the anonymous page cache, which stores the final pre-gzipped HTML keyed by (path, host, note version, config, language). A cache hit copies bytes out of memory, with no re-render and no gzip.

The effect: a default-template docs page previously cost ~28 ms/request (dominated by a synchronous per-request vector-search "similar notes" pass using cosine similarity over all note embeddings, ~94% of CPU) while a Jet landing page cost ~0.9 ms/request. After the cache warmed, both pages served at the same ~9 000 req/s. The cache equalizes cheap and expensive pages.

Benchmark: 2026-06-29, Hetzner shared-vCPU VMs

Attacked from the cx33 over the network (separate machines, cross-network).

12-second burst (max rate): ~9 000 req/s, server CPU ~78%, steal 0%.

10-minute sustained run (max rate):

Five million requests, ten minutes, zero errors.

The chart below shows how latency changes as the offered request rate climbs toward and past saturation.

p50 stays sub-millisecond up to ~6 000 req/s. The knee is at ~7 000–8 000 req/s, where p50 jumps from 1.2 ms to 146 ms. The box saturates near 9 000 req/s. Success rate was 100% throughout: the server degrades on latency under overload rather than refusing requests.

Cost framing: 8 557 req/s ≈ 739 million requests per day on a €6.49/month box — roughly €0.0003 per million requests, or about €0.29 per billion. For any realistic traffic volume, the serving cost per request is negligible.

Pre-cache comparison (12-core dev box, single page): the default-template docs page served 421 → 8 504 req/s after the cache warmed — a 20× improvement. CPU on cache hits dropped from ~95% to ~0%.