Choosing Suchi

There are several mature, actively developed self-hosted document archives. This page describes the choices built into Suchi’s design, what each one costs, and the needs another tool may meet better. Read it with the other projects’ own documentation open.

​

At a glance

• One Go binary with SQLite and a content-addressed file store; no broker or separate workers.
• Watched folder, IMAP mailboxes, upload API, and a first-party iOS/Android capture app.
• OCR, office-document and e-invoice extraction, scan splitting at archive serial number labels, and blank-page removal.
• Filing trees based on the Johnny.Decimal concept, with tags, correspondents, and typed custom fields.
• Deterministic rules, local similar-document matching, and an optional model, with uncertain changes waiting in a review queue.
• A readable folder tree on disk, kept current from templated layouts.
• Version history, named links between documents, and archive serial numbers for retained originals.
• Per-document permissions, OIDC sign-in, an audit log, and share links with expiry and passwords.
• A documented REST API and an MCP server for AI agents.

​

How Suchi works differently

​

One process to run

Suchi is one Go binary with SQLite and a content-addressed file store on disk. There is no broker, worker, or separate database server to operate; optional converters such as anydoc and OCR tools are ordinary programs on PATH. Trade-off: one process scales up rather than out. Suchi cannot spread processing across machines.

​

Your folders stay readable, and your drop folder stays yours

Folder layouts keep a browsable tree on disk, built from each document’s category, sender, dates, and title. The files in that tree are links to the stored documents, so the tree takes no extra space and still opens without Suchi. Separately, the watched folder is read-only: Suchi never moves, renames, or deletes what you drop in. Trade-off: the drop folder is never emptied for you. If you want it cleaned up, a script or sync tool has to do it. See it in practice: Keep the folder layout you already use.

​

Uncertain changes wait for a person

Rules you write apply exactly. Local matching and the optional model propose a category, title, correspondent, tags, or dates; anything below its confidence threshold, or everything if you choose Review first, waits in Approvals with the evidence beside it. Original files are never modified. Trade-off: in Review first mode, new documents stay unfiled until someone clears the queue. See it in practice: From inbox to filed.

​

Filing trees, not just tags

Suchi files every document into one category of a filing tree based on the Johnny.Decimal concept, such as 51 Utilities. Five ready-made trees are included, and tags, correspondents, and typed custom fields sit alongside. There is no separate document-type field; categories and tags do that job. Trade-off: you pick, or adapt, a tree before filing. If you only ever want free-form tags, the structure is overhead. See Filing trees.

​

A phone app for capture away from home

Suchi Companion is a first-party iOS and Android app. It scans with the phone’s document scanner, queues captures until the server is reachable, searches the archive, and keeps selected documents for offline use. Trade-off: Companion talks only to Suchi; it does not work with other archives’ APIs. See it in practice: Using Suchi Companion away from home.

​

History, relationships, and physical originals

Replacement versions keep earlier files underneath the current one, and named document links connect related documents, shown at both ends. Archive serial numbers tie a retained paper original to its scan, from a QR label or typed by hand. See it in practice: Keep a document’s history and its related documents and Linking scans to their physical originals.

​

Agents work through the same permissions

The MCP server lets an AI agent search, read, resolve approvals, create share links, and set custom fields and document links, using an ordinary scoped token. Every change goes through the same permission checks and audit log as a person’s.

​

Where Suchi falls short

• Maturity and community. Suchi is younger than the established projects, with a smaller community and fewer third-party integrations.
• PDF editing. Suchi does not rotate, reorder, or delete pages.
• Scale-out. One process; see above.

​

When another tool may fit better

Look elsewhere if you need:

• a large ecosystem of community mobile clients, plugins, and integrations;
• page-level PDF editing inside the archive;
• document processing that scales out across several machines;
• a dedicated document-type field, or free-form tags with no filing structure;
• a drop folder that is emptied automatically after import;
• several files stored together as one document.

​

Moving an existing archive

suchi import reads an export bundle from an existing archive, including originals, archive PDFs, tags, correspondents, storage paths (as folder layouts), saved views, and workflows, which map onto Suchi’s automations. It is idempotent, so you can re-run it against a nightly export and keep both systems running side by side; suchi import --verify reports what still differs. The importer targets one specific source version. Exports from newer versions may contain shapes it doesn’t recognize; those are listed as failed in the migration report for you to review rather than imported silently. See the importer guide for supported sources and versions.

​

Resource profile

The accepted v0.1 Suchi benchmark measures a 25.5 MB stripped binary, 31.9 MB median idle RSS, 86 ms cold start to /healthz, and 625 accepted upload requests/s in the 10-user × 20-document scenario. Upload acceptance is measured separately from asynchronous extraction. See hack/bench/ for the harness and machine details. These are Suchi’s own measurements; this page publishes no comparative figures. Container size and idle memory are not the same as total operational cost.

​

Portability

• Into Suchi: see Moving an existing archive.
• Suchi takeout: suchi export --out FILE.zip --system S02 --all writes a partial manifest-v3 export of that one system’s originals, sidecars and taxonomy for every owner there. Archive serial numbers are preserved when reingested into a system where the value remains available. Without --system, the original system is selected; without an owner flag, owner inference must be unambiguous. Reingestion can allocate new IDs and does not restore membership or ACLs.
• Suchi backup: preserve the whole SQLite/CAS/key set for an exact restore of systems, memberships, IDs and relationships; see Backup and restore.
• Suchi to another archive: there is no destination-specific exporter. The takeout is documented and uses ordinary files plus JSON sidecars, but mapping it into another product remains migration work.

​

Update history

• 2026-10-20: Rewrote the page around Suchi’s design choices, their trade-offs, and the needs another tool may meet better, replacing the feature matrix.
• 2026-09-28: Added the Android/iOS Suchi Companion and clarified mobile access.
• 2026-08-22: Re-ran the release benchmark and rechecked the linked documentation against the current product surfaces.
• 2026-08-18: Rechecked official documentation; corrected database, full-text search, audit, sharing, permissions, OCR, LLM, and licensing claims. Removed unmeasured performance estimates for other projects.
• 2026-08-05: Initial version.