HN Debrief

Stinkpot: SQLite-backed shell history

  • Developer Tools
  • Open Source
  • Programming

Stinkpot is a small Go utility that copies shell history into a local SQLite database and lets you search it through a text UI. The pitch is not novelty so much as subtraction. It is aimed at people who liked the core idea behind Atuin, persistent searchable history across sessions, but do not want sync, cloud features, or extra product surface. That framing shaped most of the reaction. People who already use shell-history tools largely read it as “Atuin, but thinner,” while others pointed out long-standing zsh and fish options, plus the old standby of fzf wired into normal shell history.

If your team lives in terminals all day, shell history is drifting from a throwaway text file into a queryable developer tool. The practical choice is whether you need structured features like directory-aware recall, sync, and analytics, or just want fast Ctrl-R without adding another moving part.

Discussion mood

Mostly positive and pragmatic. People liked the stripped-down alternative to Atuin, but the mood was not wowed by the concept itself because many already have workable setups with Atuin, fzf, fish, or zsh plugins. The main friction came from Stinkpot’s bash hook limitations and from skepticism that SQLite is necessary if all you want is simple history search.

Key insights

  1. 01

    PROMPT_COMMAND misses in-flight commands

    Using bash PROMPT_COMMAND means history is written only after a command returns. That makes the database incomplete in exactly the moments when recall is most useful. A long-running command that gets interrupted never lands in history, and a command you just launched in one terminal cannot be recalled from another until it finishes.

    Do not treat this capture path as a full audit trail or as real-time shared history across terminals. If that behavior matters, test the shell hook before standardizing on any history tool built this way.

      Attribution:
    • ptspts #1
  2. 02

    SQLite earns its keep through context

    The value of a database is not that plain text search is too slow. It is that indexed history can answer richer questions cheaply and continuously. Comments highlighted directory-aware recall, current-project filtering, recency weighting, status codes, execution time, ghost suggestions on each keystroke, and long-term analysis over years of commands. Persistent storage also avoids making every new bash process load a massive in-memory history file.

    If you only need reverse search, keep your setup simple. Reach for a database-backed history when you want context-aware recall, per-project workflows, or metadata you can query and build on later.

      Attribution:
    • ptspts #1
    • fpoling #1 #2
    • Kubuxu #1
    • vladvasiliu #1
    • jiehong #1
    • blepblep #1
  3. 03

    The next step is output capture

    A command line without its output loses a lot of the reason you wanted to find it again in the first place. The suggestion here was to turn history into a searchable session record, closer to saved SSH transcripts, with enough context to recover not just what was run but what happened. That immediately raises a harder problem, which is automatic secret redaction.

    If you are building internal developer tooling around shell activity, command history alone may be too thin. Consider whether the real need is session logging, then design privacy and redaction before rolling it out.

      Attribution:
    • gertrunde #1

Against the grain

  1. 01

    Text search is already fast enough

    For ordinary shell-history search, SQLite solves a problem many people do not actually have. fzf and grep stay responsive on histories with hundreds of thousands of lines, especially when the file is cached. If your use case is just finding an old command, a flat file plus a good fuzzy finder is simpler and likely indistinguishable in practice.

    Benchmark your current history flow before adopting a database. If users only care about fast Ctrl-R, adding schema, hooks, and another binary is probably wasted complexity.

      Attribution:
    • OskarS #1
  2. 02

    Perpetual history plus fzf covers basics

    A lot of the practical benefit can be had by fixing bash history behavior and binding Ctrl-R to fzf. That keeps everything in standard shell plumbing and avoids introducing another opinionated tool just to get cross-session recall and better search.

    Try the low-complexity path first. If improved shell settings and fzf satisfy your workflows, save the heavier history stack for people who truly need metadata and context filters.

      Attribution:
    • themadsens #1

In plain english

Atuin ↩
A shell history tool that stores command history in a database and adds features like search, context, and optional sync.
Bash ↩
Bourne Again Shell, the most common GNU Unix shell and a superset of many POSIX shell features.
Ctrl-R ↩
A common keyboard shortcut in shells that searches backward through command history.
fish ↩
Friendly Interactive Shell, a Unix shell focused on usability and interactive features but not full POSIX compatibility.
fzf ↩
A command-line fuzzy finder that lets you interactively search lists such as shell history, files, or command output.
PROMPT_COMMAND ↩
A Bash shell variable that runs a command before each prompt is shown, often used to update history or terminal state.
SQLite ↩
A lightweight embedded database stored in a single file, often used inside applications without a separate database server.
SSH ↩
Secure Shell, a protocol for securely connecting to and administering remote computers.
zsh ↩
Z shell, a Unix shell with many interactive features and some behavior differences from Bash and POSIX `sh`.

Reference links

Alternative shell history tools

  • Atuin
    The main comparison point. Several comments described Stinkpot as a simpler alternative to it.
  • zsh-histdb
    Presented as a lightweight SQLite-backed history option for zsh.
  • McFly
    Mentioned as another history tool with fewer extras than Atuin.
  • zsh-mouse-and-flex-search
    Shared as a custom history search approach that does not rely on Ctrl-R.
  • gtsh-hist
    Shared as a script that launches terminals with separate per-project history files.

Configuration and usage references

Related infrastructure

  • Litestream
    Suggested as a way to replicate or sync the SQLite history database across machines.
  • Tangled
    Mentioned to clarify that the project host is Tangled rather than Forgejo.