I Rebuilt My JavaScript Database From Scratch for the AI Agent Era

Tarek — Tue, 31 Mar 2026 17:49:54 +0000

Three years ago, I built Skalex - a simple, zero-dependency
in-memory document database for JavaScript. It did what it said
on the tin: store documents, query them, persist them to disk.
People used it. I was happy.

Then everything changed.

The moment I knew I had to rewrite it

AI agents became real. Not just chatbots - actual agents that
remember things, reason about data, and take actions. And as I
started building with them, I kept running into the same wall:
The database layer wasn't designed for this.

Every time I wanted an agent to recall something from a previous
session, I had to bolt on a vector database. Every time I wanted
natural language queries, I had to wire up an external service.
Every time I wanted to expose data to Claude Desktop or Cursor
via MCP, I had to build plumbing from scratch.

I was spending more time on the infrastructure than on the actual
agent logic.

So I asked myself: what would a database look like if it was
designed for AI agents from day one?

That question became Skalex v4.

The constraints I refused to compromise on

Before writing a single line, I set three rules for myself:

Zero dependencies - no supply chain risk, no bloat, no node_modules hell
One package - everything the AI stack needs, no separate installs
Every JavaScript runtime - Node.js, Bun, Deno, browsers, edge workers

These constraints made everything harder. And they made the result much better.

What I built

Vector search that just works

The most requested feature from v3 users was semantic search. I wanted it to feel native, not bolted on.

const db = new Skalex({
  ai: {
    provider: "openai",
    apiKey: process.env.OPENAI_API_KEY,
    embeddingModel: "text-embedding-3-small"
  }
});

await db.connect();

const notes = db.createCollection("notes", {
  vectorField: "content"
});

// Insert with automatic embedding generation
await notes.insert({ 
  content: "The cat sat on the mat" 
});

// Search semantically
const results = await notes.search("feline on furniture", { 
  limit: 5 
});

No separate vector database. No separate embedding pipeline. One package, one API.

Want to use local models instead? Swap the adapter:

const db = new Skalex({
  ai: {
    provider: "ollama",
    embeddingModel: "nomic-embed-text"
  }
});

Fully offline. Zero API costs.

Agent memory that survives restarts

The biggest pain point I kept seeing in AI agent code was memory that evaporated when the process died. Session memory is easy. Cross-session memory is the hard part.

Skalex solves this with a dedicated memory API backed by semantic embeddings and persistent storage:

const memory = db.useMemory("agent-1");

// Remember something
await memory.remember("User prefers dark mode and concise answers");
await memory.remember("User is building a SaaS product in Next.js");

// Recall semantically across sessions
const context = await memory.recall("user preferences", { limit: 3 });

// Compress old memories to save space
await memory.compress();

When the process restarts, db.connect() reloads everything from the storage adapter. The agent picks up exactly where it left off.

Natural language queries

db.ask() translates plain English into structured filters via any LLM:

const results = await db.ask(
  "find all users who signed up this month and haven't logged in"
);

Works with OpenAI, Anthropic, and Ollama. The LLM generates the filter, and Skalex executes it. No prompt engineering required on your end.

A one-line MCP server

This is the feature I'm most excited about. Model Context Protocol lets you expose your database as a tool to Claude Desktop, Cursor, and any MCP client:

const db = new Skalex({ path: "./data" });
await db.connect();
db.mcp().listen();

Three lines. Claude now has full read/write access to your database - find, insert, update, delete, search, ask questions in plain English. Add it to your Claude Desktop config and your AI assistant has a real persistent memory layer.

The hardest part

The hardest part wasn't the AI features. It was keeping everything in a single zero-dependency package while supporting six different runtimes.

Node.js, Bun, and Deno all handle crypto, file I/O, and module resolution differently. Browsers don't have a filesystem. Edge workers have memory constraints. Every platform is a special case.

The solution was pluggable storage adapters:

// Node.js
const db = new Skalex({ adapter: new FsAdapter("./data") });

// Browser
const db = new Skalex({ adapter: new LocalStorageAdapter() });

// Cloudflare Workers
const db = new Skalex({ adapter: new D1Adapter(env.DB) });

// Bun
const db = new Skalex({ adapter: new BunSQLiteAdapter("./db.sqlite") });

Same API. Every platform. Zero code changes in your application layer.

The test suite ended up at 787 tests across Node.js, Bun, Deno, Chrome ESM, Chrome UMD, and BunSQLite. Every commit runs all of them.

What I learned from the rewrite

Constraints are a feature. Zero dependencies forced me to implement crypto, compression, and vector math from scratch using only built-in APIs. The result is leaner and more auditable than any dependency chain.

The AI stack needs a database that understands it. Tacking vector search onto a traditional document store feels wrong because it is wrong. When memory, search, and queries are all first-class citizens, the agent code becomes dramatically simpler.

Local-first is underrated. Ollama support means you can run the entire AI stack - embeddings, LLM, database - on your laptop with no API keys, no costs, no data leaving your machine. For prototyping and privacy-sensitive workloads, that's a huge deal.

What's next

v4 is in alpha today. The API is largely stable, but may shift before the stable release. What's on the roadmap:

Hybrid BM25 + vector search with Reciprocal Rank Fusion
CRDT real-time collaboration
SQLite WASM adapter for browser-native persistence
Graph traversal queries
Framework adapters for React, Vue, Svelte, Solid, and Eleva

If you're building AI agents, CLI tools, desktop apps, or edge workers where the dataset fits in memory - give it a try.

npm install skalex@alpha

Feedback, bug reports, and contributions are what make the stable release good.

GitHub: https://github.com/TarekRaafat/skalex
Docs: https://tarekraafat.github.io/skalex

autoComplete.js library v2.0 RELEASED!

Tarek — Sun, 23 Dec 2018 21:45:41 +0000

Simple autocomplete pure vanilla Javascript library. v2.0

autoComplete.js is a simple pure vanilla Javascript library that's progressively designed for speed, high versatility and seamless integration with wide range of projects & systems, made for users and developers in mind.

An autocomplete search should feel like it’s making the user’s (End User & Developer) experience much faster, easier, more productive and more streamlined. Actually, it shouldn't feel like anything at all, the user should fly by autocomplete on their way to whatever it is they’re trying to search. That's why autoComplete.js designed and built on the following core principles.

End User:
- Simplicity
- Intuitiveness
- Usability
- Speed
Developer:
- Lightweight
- Customizable
- Zero Dependencies
- Seamless Integration
- Scalable
- Open Source

Have a look at the autoComplete.js demo, and let me know your thoughts! :)

Forem: Tarek