Tine Beta: a second, smaller Tine

[martinkoutecky]

Starting today Tine comes in two channels. Stable is the Tine you have now. Tine Beta is a separate app you can install next to it, where new work will land first from now on. This first Beta is more than a channel, though: it is a rebuilt Tine. This post says what it is, why I rebuilt it, and how it was made.

Why

Since around 0.6.9x, Tine has felt worse to many of you, and to me: writes rejected on Android, launches stuck waiting for the index, renames taking a minute on large graphs, backlinks slow or missing. Each of those got fixed, and each fix was followed by a new problem of the same kind. When I looked at why, the answer was not one bug. Tine had grown a second copy of your graph (a SQLite index kept in sync with the Markdown), plus the machinery to keep the two agreeing, and most of the recent bugs lived in the space between them. The code had roughly tripled since 0.6.5, and nobody, me included, could reason about it with confidence anymore.

How it got there: after 0.6.5 I asked an AI agent (GPT-5.6-Sol) to build Managed Storage. The work got derailed by adversarial review standards far beyond what a local notes app needs, which Sol adopted instead of stopping to ask me. Days of non-stop implementation followed and produced a great deal of code, and most of the work since has gone into trying to make that code good. Beta is the decision that starting again from 0.6.5 is easier than finishing that job.

What Beta is

Beta starts again from 0.6.5, the last version where your Markdown files were the only truth. Storage was rebuilt first, as one module that owns reading, saving, watching files and its caches, with a small interface everything else goes through. There is no database. Then every feature added since 0.6.5 was brought over, family by family (32 of them), with stable's current behaviour as the reference: queries, Concord, sheets, export, the editor changes, the settings. A few things were deliberately left out, mainly Managed Storage (already removed from stable) and the SQLite index itself.

The result does what stable does with about a third less code, and it is faster where you wait. On my test graphs, against current stable:

• starting up and running the first search: 23–41% faster
• renaming a page with 200 references: 52–62% faster, and the new title shows up in about half the time
• memory: about the same or lower
• typing, opening pages and saving: the same

These are Linux measurements; I have not measured Windows yet.

How it was made

The same agents as before, under stricter rules. Every change had to keep one place responsible for each question (what is this page's name, which blocks link here), state its cost up front, and go through the one save path. Every batch had to pass the full test suite, open and save my entire anonymised graph without changing a byte it should not, and pass end-to-end tests in the real app. Every few batches, a sweep over the whole codebase looked for rule violations and data-safety problems, and performance was measured against 0.6.5, not just against stable, so slow drift could not hide. This did not make the process bug-free. It made the bugs cheaper to find, and it kept the code from growing faster than the features.

Stable and Beta from now on

Several of you asked for a stable and a testing channel, and you were right. Stable now gets fixes for serious problems only. When this rebuilt Beta has been used enough, on enough platforms, that I trust it, it becomes the next stable release (0.7.0). After that, Beta stays: it is where new features land first, and each Beta that proves itself becomes the next stable release.

Trying it

Tine Beta 0.7.0-beta.1 is available for Linux, Windows, macOS and Android (as an APK from the GitHub release). It is a separate app with its own settings, so it installs next to stable and does not touch it. On desktop, its first launch copies your stable settings and graph list; on Android you open your graph folder once more. Beta updates itself only to newer Beta builds.

Please do not open the same graph in stable and Beta at the same time. Using both on one graph one after the other is fine.

What helps most is a report of anything Beta does worse than stable: something missing, slower, or different. The version string (it says Beta) and the steps are usually enough. Bugs that are in both versions are still welcome, but regressions are what decide when Beta can become stable.

[martinkoutecky]

@Brikas @EllisMorrow @Dieterbe @hestratos @lingkuma @da5nsy hi - you are few of those who engage with Tine the most, so I'm tagging you in hopes you could spare a moment and test this new release and report bugs that you spot. I hope it will turn out to feel better than the current master (it does for me). Thanks!

[EllisMorrow]

I'm really glad to see that Tine has already rebuilt all 32 feature families from 0.6.5 so quickly. This is much faster than I expected — I originally thought it might take 1–2 months.

I'll test the Beta and report any issues whenever I have time.

[martinkoutecky]

There has been a lot of time spent on making storage a deep module, and some other design work, but then Opus 5.5 (with subagents) basically worked almost autonomously for ~3-4 days and did the job.

Thanks for testing!

[EllisMorrow]

After installing Tine Beta 0.7.0-beta.1, I accidentally opened 0.6.987 instead, which made me mistakenly think Beta 0.7.0-beta.1 was already working very well, haha.

I have now used Tine Beta 0.7.0-beta.1 again and found the following issues, which I have submitted as [#623](#623):

1. Every time Tine Beta 0.7.0-beta.1 starts, it appears to rebuild the entire index from scratch, which makes every launch feel very slow before reaching a page. In 0.6.987, this only seems to happen on the first launch.
   (Windows 11, graph with about 13,000 pages)

2. Every time I open a page, there is a “Loading page...” delay of around 2–3 seconds.

3. After entering a page, when I click into a block, Tine frequently shows “Refreshing changes from disk.” This appears to cause obvious input lag and stuttering. Text I type or delete may take around 2–3 seconds before the action is reflected.

   This is a serious performance issue.

[EllisMorrow]

This is a Beta issue I found that clearly affects normal usage: #652

[Dieterbe]

Days of non-stop implementation followed and produced a great deal of code, and most of the work since has gone into trying to make that code good. Beta is the decision that starting again from 0.6.5 is easier than finishing that job.

Good call. With AI, it's better to be strict when merging new code, rather than trying to fix bad code later. Sometimes that means going back to the last known good version.

I never used 0.6.5 so I don't know what "peak tine" looks like. I started tine recently. In support of your awesome work, I will try to use beta as my daily driver, and report any issues. Most of my issues are already known & listed in the issue tracker. My main issue is that many queries simply don't show any result. I don't see any slowdowns similar to what @EllisMorrow reported, but i am on linux. So far, i haven't noticed a difference yet with master.

[martinkoutecky]

@Dieterbe thanks! You mean they don't show any results even on Beta? That would be kind of surprising because internally Beta and stable differ quite a lot in how they compute results (Beta simply walks over the full graph held in memory), so if these show up in Beta they have to be in the newer query work (the above-storage-layer part of it).

Linux helps (no Defender and IO is overall faster) and Ellis has a huge graph. Still good to hear.

[Dieterbe]

yes, for example a query like {{query (property type [[Person]])}} returns 0 results even though i have pages with type:: [[Person]], and the query works fine in logseq.
i have confirmed in the "about" dialog that i'm on 7.0-beta1

[martinkoutecky]

@Dieterbe thanks, reproduced: properties at the top of a page were invisible to block queries, so (property type [[Person]]) found nothing. Tracked and fixed on a Beta branch in #624 (not released yet). That issue also lists a few other query differences from Logseq found while checking. If you have another query that returns nothing, please post it there.

— Claude (working on Martin's behalf)

[sulisu]

The windows 32bit build which was introduced in v0.6.97 is missing from the 0.7.0-beta.1 release.

It is not an urgent requirement, please just bring it back when appropriate. v0.6.987 is good enough to run on my x86 win pad now.

[martinkoutecky]

I will. Glad to hear 0.6.987 runs on that, actually kinda surprised!

[Brikas]

Haha, and I thought I was the ancient here running Windows 10, but looks like someone is still in the world of 32bit Windows 😅

[martinkoutecky]

@sulisu the 32-bit Windows build is back. Both channels publish it: stable Tine 0.7.3 has Tine_0.7.3_x86-setup.exe and Tine_0.7.3_x86-portable.zip, and Tine Beta 0.8.0-beta.2 has Tine-Beta_0.8.0-beta.2_x86-setup.exe and Tine-Beta_0.8.0-beta.2_x86-portable.zip.

The 32-bit build does not update itself yet: to move to a newer release, download the next x86 installer. I could not run it on a 32-bit device here; the release pipeline only builds it. If it doesn't start on your pad, reply here with the Windows version and what you see.

— Claude (working on Martin's behalf)

[lingkuma]

Here's the version I'm using:

Windows 11
Tine Beta 0.7.0-beta.1
400 pages

---

I haven't run into the issue mentioned in #617 (reply in thread).
Switching between multiple libraries doesn't trigger a re-cache.

---

The issue at #590 has been fixed.

---

I'll keep using it, and if I run into any issues, I'll report them here.

1. When I switch graphs, in the Calendar view, the calendar at the top pops up and then disappears, as shown below:

   Scheduled & Deadlineo
   Loading query results..
   

   

[hestratos]

To be honest, I never really understood the previous architectural decisions very well. I like this approach more; everything else seemed like over-engineering to me, although I did like supporting CRDTs (technically), and also because it could enable some interesting things. But to be honest, it’s quite complicated (let’s see how https://github.com/outlmd/outl gets on).

As someone who uses several devices, synchronisation between them is also something I’d like to have (rather than relying on Syncthing as I have been doing so far), but this has always been quite complex, especially when you’re also supporting files.

I don’t know what the roadmap will look like now (7.x, 8.x milestones, etc.). I’ll keep testing and reporting things as I can, with the limited time I have.

[martinkoutecky]

I think I agree that it was overengineering, of course it did not seem so at the time. There are certainly still big benefits to being a real software engineer / knowing the platforms well and asking for specifics. For example one of my motivations for sqlite was that any indexing etc. would be done once, and then only updated incrementally. But that was very painful. Yesterday I told Claude if we could just dump the internal caches/indices similarly to how python can pickle its objects, claude said "why yes of course" and this seems to be working fine, it's fast, small, and does not add essentially any new storage layer etc. But if I did not know that in python you can pickle objects I would not know to ask for this and likely would have ended up with something much more complicated.

Anyway, we shall see. Thanks for testing, much appreciated!

[hestratos]

I think that by “pickle object” you mean “serialisation”. SQL has advantages in terms of memory usage and concurrency (and ACID): you don’t need to have the whole database loaded into memory, and several instances accessing the same graph won’t corrupt the index or whatever.

But the question is: do you actually need it? Is there a memory constraint? Perhaps on a mobile device, if you have a really huge graph. Even in that case, though, using AI you could implement a paging system similar to what a database index does, and even the index itself would be much smaller than the whole graph.

Many outliners use a database (SQLite), but I think that’s a very complex architecture. Seriously, do people really have 100k files or 100 MB of Markdown pages? Do we actually need to scale for that?. Having a fast rust core will solve most of the problems

[EllisMorrow]

One thing I would be careful about is using today's graph sizes as the long-term assumption.

A personal knowledge base can accumulate for decades. Mine already has around 13,000 pages, and at the current rate I could easily imagine it reaching 40,000–50,000 within another five or six years.

There is also some value in leaving reasonable headroom for how note-taking itself may change. With AI becoming part of the workflow, it is quite possible that in the future a significant amount of notes, summaries, references, or generated knowledge will be created by AI rather than manually by humans, and the amount of data could grow much faster than it does today.

So I agree that Tine probably shouldn't add a lot of architectural complexity just for a hypothetical 100k-file graph. But I also wouldn't design too closely around today's typical usage and then have to rebuild the architecture again if usage patterns change.

Perhaps the useful goal is to keep the architecture simple while still leaving enough scaling headroom, and benchmark where it actually starts to struggle — for example at 10k, 50k and 100k pages.

[Dieterbe]

@martinkoutecky :

There are certainly still big benefits to being a real software engineer / knowing the platforms well and asking for specifics

It may help to instruct claude to think creatively and propose various different ideas to go about solving a problem, which you can then hash out further and see which is best suited. it may still not truly think "out of the box" in the way a person would. for this reason, it may make sense to incorporate feedback from the community. This could be a high-leverage point to allow people to contribute (during the ideation/planning/design phase). Perhaps a tool like Zed's Delta would be a useful tool to support such a workflow, or as a more lightweight starting point, making technical plans a bit more explicit and easier to contribute to via PR's (see #592)

@hestratos :

SQL has advantages in terms of memory usage and concurrency (and ACID): you don’t need to have the whole database loaded into memory, and several instances accessing the same graph won’t corrupt the index or whatever. (...) you could implement a paging system similar to what a database index does, and even the index itself would be much smaller than the whole graph

The first part of this quote is framed too absolutely, which you also address in the 2nd part of the quote (and which I agree with). So just for clarity, here's my POV:

• Serialization is just conversion between values and bytes. it's trivial to build a serialization-based offloader that only keeps hot data in memory.
• there are many ways to implement safe concurrency by ourselves or use existing non-sql storage libraries (e.g. redb, rocksdb, etc).
• the main issue here however, is we're talking about solutions in the abstract. We should hash out requirements & desired tradeoffs etc and find the right solution from there.

@EllisMorrow exactly! completely agree!

@martinkoutecky I think the key things to think about are:

• How can we avoid the mistake of merging code to master that will complicate the codebase needlessly and increase the odds of future bugs and challenging refactors?
• I think a few things can help:
  1. involving community in planning/design work (see above)
  2. community feedback before "committing" to a significant piece of work (e.g. before merging to master)
  3. implementing some of the ideas in suggestion to build tine more as a "factory" #601 ; I think also here the community could help, and it may make sense to allow community PR's that work only on the guardrails, rust code guidelines etc, not on the tine code itself.

[Dieterbe]

beta2 is a huge improvement over beta1. been really enjoying this build.

[EllisMorrow]

Indeed, it does. It almost feels like a completely new app.

[Dieterbe]

and now beta3 just came out 🎉