Polywise: a self-hosted agentic content system built on SQLite and sqlite-vec

The problem Polywise targets: chat history that stops being useful

Most chat interfaces treat a conversation as a disposable transcript. You ask something, you get an answer, and the answer is gone the moment the window closes. If you want that answer later you scroll, or you copy it into a notes app, and the connection between the two is manual. Polywise is aimed at people who keep hitting that wall: engineers and researchers who ask real questions repeatedly, accumulate answers worth keeping, and want the system to resurface them without being told where to look. The README frames the motivation around memory rather than storage, describing a system that forms connections and strengthens through use. That is the pitch. The concrete deliverable is a self-hosted service with a browser UI at http://localhost:3072/app/, a CLI installed via npm install -g polywise, and a desktop build. It is for someone who wants their notes, their retrieval index and their chat in one place they control, and who is willing to run a local process to get it.

How the pieces fit: SQLite, sqlite-vec, and a thin CLI over the API

The architecture visible in the repository is deliberately small. Polywise stores data in SQLite, and vector search comes from sqlite-vec, the extension listed in the acknowledgments. There is no Postgres, no Redis, no separate vector service. That single choice explains most of the deployment story: the whole system is one process plus one database file, which is why the CLI can be described as a thin wrapper over the backend API rather than a client that orchestrates anything itself. The CLI talks to http://localhost:3072 by default, and POLYWISE_SERVER_URL redirects it elsewhere. On top of that store sit four surfaces named in the README: Session for asking questions, Linkcase for fetching and extracting web content, Agent for turning repeated instruction styles into reusable collaborators, and Posts for knowledge that should outlive a chat reply. Retrieval is not a single index. The search command accepts a for_types filter, and the README's JSON example passes ["wiki","memory"] as the set to search across, which implies at least two distinct content stores behind one query interface. The topics list mentions graph-rag alongside rag, but the README does not describe a graph traversal step, so treat that as unverified.

Getting it running: two commands and three settings

The install path is short. Install the CLI globally with npm install -g polywise, then run polywise start to keep the service in the foreground or polywise start -d to leave it running in the background. The web UI answers at http://localhost:3072/app/. For the desktop route, download the build from GitHub Releases; the README positions that as the easier way to explore sessions, saved content, agents and posts. Configuration on first run is intentionally narrow. The README says Polywise mainly needs one available model provider, plus embedding and rerank models if you want saved-content retrieval. The quick start names the exact screens: Settings -> Model Provider to add a provider you can actually use, then Settings -> Model Setting to confirm the default chat model is available. Auth is off by default and can be enabled in settings with a password; the README recommends it if you expose Polywise on a server. Two shortcuts carry most of the daily workflow: @ pulls files, agents and other context into a session, and / pulls tools and skills into the workflow. The CLI has a discoverable surface: polywise -h, polywise session -h, polywise session create -h, and polywise input_schema session.create when you need the exact input shape for a command. Upgrades are polywise upgrade for the CLI, or a fresh release install for the desktop app.

Where Polywise gets awkward: retrieval quality and release churn

The retrieval story depends on embeddings and a rerank model, and the README is explicit that these are optional for a first run. That means the default experience is chat plus saved content, not semantic recall. If you skip the embedding and rerank models, mentioning a saved item in chat will not necessarily find it, and the quick start's fifth step (mention the saved item again to verify retrieval) is the test that will fail. The second limitation is release cadence. Three tagged releases, v0.1.1, v0.1.2 and v0.1.3, landed on 2026-06-10, with the last push the following day. That is a project still finding its command shapes. The README already warns that payloads get complex enough to need raw JSON, and polywise input_schema exists precisely because the input shape is not obvious from the command name. Anyone building scripts against the CLI should expect to re-read input_schema after an upgrade. Third, Auth is opt-in. The README notes it matters when deploying as a service for remote access, which is a polite way of saying an unconfigured instance reachable from a network has no login in front of it.

How it compares to running a vector database next to your notes

The obvious alternative is the conventional stack: a hosted or self-managed vector store such as Qdrant or pgvector, plus whatever note tool you already use, wired together with your own ingestion code. That approach scales further and gives you a query language and dashboards you can inspect. It also asks you to run and back up a second stateful service, and to write the glue that turns a note into a chunk, a chunk into an embedding, and a query into a filtered search. Polywise collapses that: sqlite-vec means the index lives in the same file as the content, and the Linkcase surface handles fetching and extracting web content so you are not writing a scraper. The trade is control. With a dedicated vector database you can tune index parameters, swap embedding models without touching application code, and point a BI tool at the store. With Polywise you get the retrieval behaviour the project ships, filtered by for_types, and you inspect it through the app or the CLI. A second alternative worth naming is simply not building this at all: if your saved knowledge is a handful of documents, a grep-able folder is faster to set up and has no model provider dependency. Polywise earns its place when the volume and the cross-referencing justify an index.

Maintenance cost, licensing, and what the MIT tag actually covers

Polywise is MIT-licensed, which is permissive and imposes no copyleft obligation on your own code. It also means no warranty and no support commitment from the maintainers. The practical maintenance burden is not the licence, it is the moving parts around it. You own the model provider bills, you own the embedding and rerank model choices, and you own the SQLite file, including its backups. Because the vector index lives inside that file, a backup strategy that copies the database is also your retrieval backup, which is simpler than coordinating two stores. Upgrades are cheap to run but not risk-free: polywise upgrade replaces the CLI, and the README does not describe a migration step or a rollback path. On a v0.1.x project with three releases in two days, pinning a known-good version and reading the release notes before upgrading is the difference between a quiet upgrade and a broken script. The desktop app sidesteps the CLI version question but reintroduces it as an installer you have to re-download from GitHub Releases.

Who should install it, and what to check before you do

Polywise fits a single operator or a small team that wants chat, saved content and retrieval in one self-hosted process, and that already has a model provider it can call. It fits people who like the idea of a memory layer they can inspect as a file on disk rather than a managed service. It does not fit anyone who needs a stable integration surface today, since the CLI payload shapes are still being revised, and it does not fit anyone who needs per-user data isolation out of the box, because Auth is a single login toggle rather than a multi-tenant model. Before installing, confirm three things. First, that you have a provider key and a default chat model that works, since Settings -> Model Provider and Settings -> Model Setting are the gate to everything else. Second, that you have embedding and rerank models available, because without them the retrieval half of the product is inert. Third, that you know where the service will run and whether Auth is enabled, since an instance on a public host without it exposes the API. Then run polywise start, open http://localhost:3072/app/, ask one real question, save one answer, and search for it. That sequence tells you more about whether Polywise fits than any feature list.

Editorial conclusion

Adopt Polywise if you want a single self-hosted process that keeps sessions, saved notes and retrieval in one SQLite file, and you are comfortable pinning to a v0.1.x release. Do not adopt it if you need a stable plugin API, multi-tenant isolation, or retrieval quality you can measure before committing. Before installing, verify three things: that your machine has a model provider you can actually call, that the embedding and rerank models you intend to use are supported in Settings -> Model Setting, and that POLYWISE_SERVER_URL matches where you run polywise start. Check the v0.1.1 to v0.1.3 changelogs for breaking changes to CLI payload shapes, because three releases landed in two days.

Official sources

1. License: MIT
2. MatrixAges/polywise on GitHub
3. Project website
4. README
5. Releases