Persistent AI memory for SQL databases without re-learning

Developing a local coding assistant revealed a harsh truth: even the smartest models struggle on consumer hardware. While my 16GB MacBook could run Qwen3, the output quality never matched leading cloud services like Claude or GPT-5. The issue wasn’t processing power—it was context.

Every conversation with an AI about our SQL database began with the same tedious rediscovery:

• What does status = 3 actually mean?
• How does the orders table connect to users?
• What are those cryptic integer codes in the JobStatus enum?

The model figured it out, the session ended, and the next day it started fresh. Same tokens spent, same latency incurred, every single time. The real inefficiency wasn’t in the AI’s thinking—it was in repeatedly teaching it things it already knew.

Why input tokens matter more than output ones

Most optimization efforts focus on reducing AI output tokens—simpler language, stripped pleasantries, or truncation. But in real workflows, the bigger drain comes from input tokens. Every new session re-establishes context that never changes, wasting budget on redundant schema explanations.

Current AI client "memory" features solve this problem poorly. They’re proprietary, locked to specific tools, and often opaque. Claude’s memory doesn’t sync with Cursor. Cursor’s doesn’t transfer to Copilot. Worse, these systems are impossible to inspect, share, or version-control.

What developers actually need is an explicit, inspectable, and shareable context layer—one that any AI client can read consistently, the same way every time, and that teams can hand off without friction.

Building amnesic: persistent SQL memory for AI workflows

amnesic is an open-source MCP server that provides persistent semantic memory for SQL databases. Despite the ironic name, it remembers everything—so AI tools don’t have to.

The setup is simple: annotate tables or columns once, and those annotations persist across sessions and clients. For example:

db_annotate(
    table="orders",
    column="status",
    column_description="Order lifecycle state",
    enum_values={
        "1": "pending",
        "2": "shipped",
        "3": "cancelled",
        "4": "delivered"
    }
)

These annotations live in a local SQLite file. Future queries automatically merge them into responses:

User: How many cancelled orders this month?

AI: [calls db_get_schema("orders")]

Resolves status column to enum {3: "cancelled", ...}

Generates correct SQL immediately:

SELECT COUNT(*) FROM orders WHERE status = 3 AND ...

No re-explaining. No wasted turns. The context persists indefinitely.

Technical choices that make amnesic lightweight

Several design decisions ensure the tool remains practical for local development:

• SQLite FTS5 over vector databases: Started with ChromaDB for semantic search, but replaced it with SQLite’s built-in FTS5 using BM25 ranking. Eliminates 50MB+ embedding stacks while providing instant table/column lookup:

db_search("payment")
# Returns ranked results: orders.payment_method, consumerpayments table, ...
# All from a local FTS5 index with zero external dependencies

• Read-only enforcement in two layers: Critical when connecting to production databases. First layer statically analyzes SQL for write keywords, catching mutations in CTEs or disguised writes. Second layer wraps every query in a transaction that’s immediately rolled back—even if the first layer fails.

• Single SQLite file per connection: Schema cache, annotations, foreign key graphs, and FTS5 indexes all live in one portable file. Share it with teammates via scp or version control. Need to debug? Open it in any SQLite browser.

• Data minimization by design: Well-annotated schemas let the AI answer most questions from local knowledge without querying the database. "What does status=3 mean?" resolves from annotations. "How do orders join users?" comes from the FK graph. This reduces sensitive row data ever leaving your machine compared to naive SQL MCP servers that run SELECT DISTINCT status FROM orders repeatedly.

What amnesic doesn’t do

It’s important to clarify boundaries:

• It doesn’t enhance the model’s reasoning capabilities
• It doesn’t convert natural language to SQL queries
• It’s not an execution-focused MCP server (those handle live introspection better)

Its sole purpose is providing persistent, annotated context—the missing layer that existing tools lack.

Getting started with amnesic

Installation is straightforward:

pip install amnesic
amnesic init  # Interactive setup wizard

Add the server to your AI client’s mcp.json configuration and restart. Supports PostgreSQL, MySQL, Microsoft SQL Server, and SQLite. MIT-licensed, available on PyPI, and registered with the Linux Foundation MCP Registry.

The project welcomes feedback, especially regarding the robust read-only enforcement—an area where failure isn’t an option. Contributions via issues or pull requests are encouraged.

Rethinking AI efficiency beyond model size

The lesson here isn’t about making models bigger or faster. It’s about recognizing that some AI inefficiencies stem from architectural gaps—not computational ones. A deterministic, inspectable context layer that persists across sessions and tools transforms workflows more effectively than chasing the next benchmark.

In a world where context reuse saves more tokens than prompt engineering, tools like amnesic represent a fundamental shift: giving AI the permanent memory it needs to stop relearning the same things every session.