Ulysses and Devonthink

Which Ulysses features aren’t supported with markdown files?

From:

If you store your sheets as Markdown files there are a few constraints you should know about:

  • Local images cannot be embedded. You can, of course, use external image URLs to link to images on the web. This way they are included in the export.
  • Most attachments are not available. You can attach keywords in Markdown files. However, you cannot attach notes, images or sheet-specific goals.
  • Markdown XL tags (Comments, Annotations, Delete) are not part of the original Markdown syntax specification and therefore not available.
1 Like

Interesting. Is it still worth the subscription if you forego all that to work directly with plaintext .md files?

To be honest I haven’t used it much that way, and I don’t think it’s worth a subscription then as you lose out on the Ulysses-specific organisation and long-form writing features (iA Writer is probably a better choice here then).

I do have it set up for a couple of external folders on iOS & iPadOS, including the Obsidian vault, for when I want to make a quick change somewhere and don’t feel like using the Obsidian mobile app. However iA Writer is also better for that quick edit of a plaintext .md file, at least currently, as Ulysses does not support internal links ([[ … ]]) (apparently support for that is coming).

1 Like

The Beta is out and it does support internal linking.

In theory this is true but the definition of extremely large is usually in the multiple terabytes now or larger. Even a lightweight database system like SQLite can handle large databases. The maximum size is 140 terabytes.

The largest one I personally use is my Lightroom database which is 291MB and stores data on 35,000 pictures. My sheep database has records on over 15K animals and some tables have over 50,000 records in them and it’s only 28MB.

Performance of a database is far more affected by how well written the queries are not the number of records or the size for most normal applications.

4 Likes

That is helpful, it puts things into context, much appreciated.

Define extremely large.

1 Like

I wish I had an intelligent answer, but I don’t. My concern is probably PTSD from my old Windows days when I’d encounter the Blue Screen of Death or, in other instances, when I’d lose data through file corruption. I take it from your comment and those above that I need not worry about “extremely large” databases becoming slow or corrupted due to sheer size, correct?

Yes. Red-herring and probably propagation of FUD. Large is larger than you fear. Pick a number and make it bigger.

2 Likes

Here is the treatise on database size…

Size in gigabytes isn’t the critical number. If you check out File > Database Properties for a given database, the number of words / unique words are more critical. On a modern machine with 16GB RAM, a comfortable top limit is 300,000,000 words, 4,000,000 unique words, or 250,000 items in a database. (Note: This does not scale in a linear way, so doubling the RAM wouldn’t necessarily double those limits.) So text content in a database is far more important.

  • If you have a database of images, it will have very few words but be large in gigabytes.
  • If you have a database of emails, it will have many words, but may be smaller in gigabytes.

The second one may perform more poorly as the number of words increases beyond the comfortable limit. Obviously, available machine resources has an effect, e.g., running 20 apps in the background, a browser with 100 open tabs sitting idle, etc.

Smaller, more focused databases will generally perform better, sync faster, and be more data-safe in the event of a catastrophe (avoiding the “all your eggs in one basket” problem).
They also give you the opportunity to close unused databases when you’re not using them. This frees up resources, not only for DEVONthink, but the rest of the system. There is no benefit to having a bunch of unused databases open all the time.

And yes, we have some people who exceed those soft limits.

3 Likes

Thank you, I learned a lot from your reply.

I assume that OCRed PDFs count as words. Would that be correct?

Most of what I have in DT are PDFs of research literature. I keep separate databases for Research, AN archives, Writing archives, and more. I opted for this approach to avoid, as much as possible, losing everything if one database becomes corrupted. Your explanation makes me feel a lot better!

This worry can be mitigated with backups, and supplemented by database archives as zip files.

2 Likes

You’re welcome and yes, a PDF with a text layer has a word count which contributes to the overall size of a database’s index.

I have nearly 4,000,000 unique words here… Well, now I know why Devonthink runs so slow on my M1 8GB Air…

as so large can probably split into 2 or more databases?

Note 8GB is pretty low RAM for a modern machine. Always opt for the most RAM you can reasonably afford, especially as modding a Mac isn’t as simple as modding a PC. :slight_smile: