What is a SQLite database?

A whole database that lives in a single file on your computer. No server. No admin. No login. The thing most agent harnesses use to give your agent a memory.

I open my OpenCLAW memory folder. Inside it is a file called memory.db, sitting next to my SKILL.md files and my CLAUDE.md. That single file holds every commitment my agent has tracked for me, every Granola transcript indexed for search, every decision-log entry I have written in the last six months. It is forty-seven megabytes. It backs up to iCloud automatically. That is the whole infrastructure.

The first time a CEO asks me how my agent "remembers" things between sessions, the answer is usually this file. It is the most valuable artifact in my install, and almost nobody knows it is there.

What it is

SQLite is a database that lives in a single file on your computer. Not on a server. Not in the cloud. Just a file, usually with a .db or .sqlite extension, sitting in a folder. You do not install it as a service. You do not log in to it. Most apps that need to remember things embed SQLite invisibly.

You almost certainly already use SQLite without knowing it. iPhone Photos uses SQLite to track your library. Firefox uses SQLite for bookmarks and history. WhatsApp uses SQLite for your message archive. The format is the most-deployed database in the world by a wide margin; it ships on every phone, every Mac, every Linux machine.

For an agent harness, SQLite is usually the layer that gives the agent persistent memory. When your agent says "I remember that you decided in Q2 to pause senior hiring in sales," it is reading that fact out of a SQLite file. When you ask "what did I commit to in last week's leadership meeting?" the agent is running a full-text search across the SQLite database that holds your indexed transcripts.

Why it matters

A database in a single file flips three things for a CEO running AI.

Portability. Copy the file, you copied the database. Move it to a new laptop and the agent's memory comes with it. Compare that to a cloud database, where moving providers is a project.

No admin. SQLite has no password to rotate, no patches to install, no server to keep running, no scaling decision to make. The file exists or it does not. When it gets big, it gets bigger. There is nothing to operate.

Inspectable. The file is yours, on your machine. You can open it with a free tool (DB Browser for SQLite is the standard one) and look at every row your agent has written. You can see what it remembers. You can see what it forgot. If something looks wrong, you can read the data and reason about it.

The reason most serious agent harnesses use SQLite under the hood is that those three properties matter more for a CEO than the things a cloud database is better at (handling thousands of concurrent users, replicating across continents). A CEO running an agent is one user with one machine. SQLite is sized for the job.

What a good one looks like

The SQLite file your harness writes to should:

• Live in a folder that backs up automatically. iCloud Drive, Dropbox, Backblaze, whatever you already use. Lose the file, lose your agent's memory. The file is irreplaceable in a way most of your other files are not.
• Not get committed to git if it has private content. Most agent memory contains customer names, deal values, internal decisions. Treat the .db file like a secret. Add it to your .gitignore.
• Get a copy stashed somewhere off your laptop. Daily backup is fine. Weekly is OK. Never is a problem.
• Stay readable. If your harness offers a way to export the contents to markdown or JSON, run that export every few months. Format migrations are rare but they happen, and a markdown export gives you a fallback that does not depend on SQLite continuing to exist.

The healthy size for a single-CEO agent memory is a few megabytes to a few hundred megabytes. If you cross a gigabyte, something is logging too much.

Common mistakes

Forgetting the file is there. The first time most CEOs go looking for "where my agent's memory lives," they discover the SQLite file has been sitting in a hidden folder for months, with no backup and no plan. Find it in your first week. Know where it is.

Treating it like ordinary text. A SQLite file is binary. You cannot open it in a text editor and read it like a Word doc. You need DB Browser for SQLite (free) or a similar tool to inspect it. Do not edit it by hand even with those tools; let the agent write to it.

Committing it to git. I have seen CEOs commit their agent's memory to a public GitHub repo by accident, complete with customer names and internal pricing. Add *.db to your .gitignore on day one.

No backup. A SQLite file on a laptop with no backup is the most important thing on your install most likely to be lost. The day the laptop falls in the pool is not the day to start a backup plan.

Storing secrets in it. Some agents will write whatever you tell them into the database, including credentials if you paste them. Audit what is in the file once a quarter. The agent is only as careful with your secrets as you tell it to be.

Do this next

Find the SQLite file your harness writes to. It usually lives in your home folder under a hidden directory named after the harness (try looking for a folder like .openclaw or .hermes). Confirm three things: (1) the file is in a folder that backs up, (2) the file is in your .gitignore if you are version-controlling that folder, and (3) you know how to open it with DB Browser for SQLite if you ever need to look inside. Ten minutes of work. The most valuable file in your install deserves the attention.