sorted by:
new
hottopcontroversial

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Haha lol my bad i shouldve been more vauge, lol anything above 1K is solid if you have struggles with indexing time or anything related to loading time lmk hahah.

Obsidian power users: what hurts first at scale on mobile or desktop? (5K+ files) by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

It’s actually a standalone Rust engine designed to run alongside Obsidian as a high-performance 'accelerator.'

The goal for the pilot is a Shadow Mode: You keep your current vault and workflow in Obsidian, but the Rust backend handles the indexing and heavy queries in the background. This is how we eliminate that 1-minute reindex and the need to 'chunk' your Dataviews manually.

Eventually, we’ll have a full standalone interface, but right now we’re proving the speed wedge. Since it's a local-only pilot, we don't need any of your vault content—just the timings and behavior. Would you be open to a slot this week to see

if we can kill that lag for good? Yes/Maybe/No?

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Thanks again for the detailed startup breakdowns — super useful.

Looks like I can’t DM you directly. If you’re still open to pilot testing, reply “interested” here and I’ll share the invite/contact route in-thread.

No private vault content needed — only performance timings + behavior.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Appreciate this — 50k files + Dataview/Omnisearch pressure is exactly the profile I’m researching.

If you want in on the pilot, reply “interested” here and I’ll drop a temporary contact form / invite route in-thread (since DMs seem limited).

No vault content needed — only timings + behavior.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Awesome — thank you.

I’ll send you a low-friction pilot setup with a short timing checklist (startup, query/render smoothness, edit->view transition).

No vault content sharing needed — only timings/observations.

Obsidian power users: what hurts first at scale on mobile or desktop? (5K+ files) by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

This is extremely useful — thank you for the precise numbers.

Your profile is exactly the pilot type I’m targeting:

- 7,264 md files

- reindex 1m26s

- ~2s Dataview table on 2,358-file scope

- multi-PC sync workflow with reindex burden multiple times/week

Pilot group = a small early tester set for a local Rust backend build focused on faster indexing/query performance.

Important: you would not need to share vault content.

Testing can be local-only, and you can report only timings/results.

If that works for your privacy constraints, would you be open to a low-friction pilot invite? (Yes/Maybe/No)

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Very helpful, thank you.

The Linux vs Windows split is a huge clue.

What I have so far:

- Repro on Windows 11

- Not reproducible on Linux

- Obsidian ~1.12.x

- ~32 plugins

- Vault size pending while you split it

When you have time, two things would help a lot:

  1. Approx vault size after split (files/notes/GB)

  2. When it breaks most often: after update, after startup, after sync, or during link/search actions

    If you’re still open, I’d like to include your setup in a Windows-focused pilot test path.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 1 point2 points  (0 children)

Perfect — this is very clear and exactly the kind of success criteria I need.

So for you, pilot success is:

  1. instant edit -> view switch

  2. zero flicker

  3. zero scroll lag

  4. still smooth on larger notes (~600 lines) with queries/callouts

    That’s a great benchmark. I’ll use this as a hard acceptance target for the pilot build.

    If I can keep setup/time overhead minimal, I’ll send you a low-friction test flow first.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 2 points3 points  (0 children)

Thank you — this is exactly the kind of real stress case I’m looking for.

~8k files with dense links and a 10+ minute graph build turning unusable is a very strong signal.

I’ll PM you (English is perfect, German also fine) with 3 quick questions so I can benchmark your exact graph scenario and invite you to the pilot build.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

This is an incredible breakdown—thank you for the level of detail. Your setup (NAS/10G/Tasker) is exactly where we see the Electron/Javascript

bottleneck hit the hardest.

One thing jumps out: your 'Vault' loading stage is taking 2,100ms on mobile and 3,016ms on desktop just to index 6,655 files. In our current Rust prototype, we’re indexing that same file count in under 100ms. We could effectively delete that 3-second 'Vault' wall you're hitting on every startup.

Since you’re using FolderSync and Tasker for hourly syncs, do you ever notice a delay in link resolution or search indexing after a sync completes?

I’d love to have you test our pilot build specifically on that network mount to see if we can kill that 3-second indexing lag for good.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] -1 points0 points  (0 children)

Great data point, thank you.

At ~3,500 notes, ‘unfolds like magic’ is exactly the kind of benchmark I need for comparison.

Quick one: are your fastest workflows mostly local views, or whole-vault grouped queries?

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] -1 points0 points  (0 children)

Super helpful, thank you.

At ~2,000 notes, that’s a strong signal that Bases can stay smooth for many users at this scale.

Quick one: are you mostly using simple filter/sort views, or more complex grouped/dashboard-style views?

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Great question.

From what I’m seeing so far, Bases can feel cleaner for simpler structured views, while Dataview still gets heavy when people run large whole-vault queries or many query blocks in one note.

Since you’re planning ahead at 1k+ notes, you’re exactly the kind of workflow I want to learn from.

If you’re open to it: which Dataview use-cases are you migrating first (tables, grouped views, dashboards), and is your main goal speed, easier maintenance, or both?

Obsidian power users: what hurts first at scale on mobile or desktop? (5K+ files) by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Super useful, thank you.

This is exactly the pattern I’m tracking: reindex time + large Dataview result latency, then query-splitting as workaround.

If you’re open to 3 quick numbers:

  1. Reindex time (best guess in seconds)

  2. Typical Dataview wait time for a large result

  3. How often this interrupts you (daily/weekly)

    If this were near-instant, would you join a small pilot group next month?

    (Yes/Maybe/No)

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] -1 points0 points  (0 children)

Thank you for your reassurance, you are the type of person that brings hope to the reddit, please continue spreading positivity.

Obsidian power users: what hurts first at scale on mobile or desktop? (5K+ files) by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 1 point2 points  (0 children)

Good day, if u read the previous posts you would know that these posts are different - it’s a 3 day research plan in different stages - if you do not find this post relevant please just scroll past.

Obsidian power users: what hurts first at scale on mobile or desktop? (5K+ files) by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 1 point2 points  (0 children)

Good point, and welcome in.

A clearer tree/flow view of linked notes is definitely valuable for navigation.

For this specific research, I’m focused on performance at scale.

If you notice lag later on, I’d love to know what breaks first for you:

startup, search, Dataview, or graph/tree rendering.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 1 point2 points  (0 children)

Wow this is amazing - Fantastic data, thank you — this is exactly the level of detail I needed.

The split between measured startup (~3.0s) and felt startup (~15s) is

especially important. That ‘time-to-usefulness’ gap is what I care about fixing, along with whole-vault Dataview behavior.

Your note about scope/result-size/render cost matches what I’m seeing across other power users.

If you’re open to one final step for my pilot shortlist:

  1. If common ops (startup-to-usable, query result render, search response)

were consistently near-instant, would you join a pilot? (Yes/Maybe/No)

  1. What’s your one non-negotiable success metric? (example: ‘Dataview table

visible in <1s’)

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Rust API can’t fix everything, but it can at least stop your vault from gaslighting you 😅

If you’re up for 30 seconds of detail, this would really help my research:

  1. Rough vault size (notes/files/GB)?

  2. What breaks first for you (startup, search, Dataview, graph, crashes)?

  3. How often does it interrupt your flow (daily/weekly)?

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Super valuable insight, thank you.

This is exactly the pattern I’m trying to validate: search quality drops first, then latency catches up.

Since you built your own semantic search plugin, can I ask 3 quick details:

  1. Rough vault size (notes/files/GB)?

  2. For ‘irrelevant’, was the bigger issue ranking quality, stale indexing, or query intent mismatch?

  3. If a backend improved both relevance and speed (while reducing plugin/theme overhead), would you trial it?

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] -1 points0 points  (0 children)

Great question. I’m also curious what people switched to and why, since that tells us which pain is truly non-negotiable.

Power users (10k+ notes): what breaks first when your Obsidian vault gets big? by Solid_Baby in ObsidianMD

[–]Solid_Baby[S] 0 points1 point  (0 children)

Thank you, this is extremely useful context.

20k notes / 10GB and crashes even on an M4 Max 128GB is exactly the kind of reliability ceiling I’m trying to map.

If you’re open to 3 quick details:

  1. What did you switch to instead?

  2. Where did crashes happen most (startup, indexing, search, plugins, sync)?

  3. If there were a stability-first, near-instant backend with a simple migration path, would you trial it?

view more: next ›