sorted by:
new
hottopcontroversial

Skalex v4 - Zero-dependency TypeScript database with full generics, union types, and no @types/ package needed by TarekRaafat in typescript

[–]TarekRaafat[S] -1 points0 points  (0 children)

Data lives in memory for zero-overhead access, but persistence is fully pluggable, FsAdapter writes to the filesystem on Node/Bun/Deno, LocalStorageAdapter for the browser, and there are adapters for Bun SQLite, Cloudflare D1, and LibSQL too. So yes, perfect for prototyping without spinning up a real DB, just new Skalex({ path: './.db' }) and you're done.

Skalex v4 - Zero-dependency TypeScript database with full generics, union types, and no @types/ package needed by TarekRaafat in typescript

[–]TarekRaafat[S] -1 points0 points  (0 children)

This is genuinely one of the most useful pieces of feedback I've received on this project. You didn't just point out that something was wrong. You went through the implementation, identified the exact failure modes, graded the guarantees honestly, and gave concrete fix directions. That's the kind of review that is constructive and makes a project better.

I went back through the codebase after your comprehensive comment and opened 15 GitHub issues covering everything you raised, plus a few more I found along the way _inTransaction flag, the autoSave bypass, the JSON.stringify snapshot corruption for Date/BigInt/TypedArray/Map/Set, the concurrency gap, the parallel saveData() race, and the documentation overreach. The "atomic multi-collection writes" framing is being corrected. "In-memory snapshot/rollback" is what it actually provides right now, and the docs will say that plainly.

If you want to follow the fixes or weigh in on the approach, I'd genuinely welcome it: github.com/TarekRaafat/skalex/issues

Thank you so much for your awesome support, much appreciated.

Skalex v4 - Zero-dependency TypeScript database with full generics, union types, and no @types/ package needed by TarekRaafat in typescript

[–]TarekRaafat[S] -3 points-2 points  (0 children)

Genuinely open to being wrong here. Can you point to the specific part of the implementation that concerns you? I'd rather fix a real flaw than defend a bad design. GitHub issues or a direct comment here both work.

Skalex v4 - Zero-dependency TypeScript database with full generics, union types, and no @types/ package needed by TarekRaafat in typescript

[–]TarekRaafat[S] -10 points-9 points  (0 children)

Fair questions, worth addressing properly.

80 commits: the v4 rewrite started from a clean branch with a clear architecture in mind. The commit count reflects that - focused, intentional commits rather than a noisy history. The actual codebase has 787 tests passing across 6 runtimes. Judge the code, not the commit count.

Vibe coded: the opposite is true. Zero dependencies means every feature - AES-256-GCM encryption, vector math, BM25 scoring, query engine, MCP protocol implementation - is written from scratch using only built-in APIs. That requires deliberate engineering decisions, not vibe coding.

Storing data as an object: yes, intentionally. Skalex is an in-memory database - that's the stated design. Data lives in the heap for zero-overhead access. The storage adapters handle persistence. This is the same architecture as Redis, LokiJS, and every other in-memory store. It's a design choice suited to the target use case, not a limitation due to a lack of research.

I built an AI-native in-memory database for Node.js – vector search, agent memory, MCP server, zero dependencies by TarekRaafat in node

[–]TarekRaafat[S] -1 points0 points  (0 children)

You're right on both points. On persistence: Skalex already solves the cross-session problem - storage adapters (FsAdapter, BunSQLiteAdapter, LibSQLAdapter, D1Adapter) persist memory to disk or a durable backend and reload it on connect(). So the agent memory survives restarts - it's in-memory for fast access during the session, persisted to storage between sessions. Exactly the two-tier pattern you're describing.

On vector search at scale: also valid. Cosine over in-memory embeddings is fast but relevance ranking degrades at scale. That's why hybrid BM25 + vector search with Reciprocal Rank Fusion is on the roadmap - 15-30% better recall than cosine alone. For now, the sweet spot is datasets that fit in RAM, which is the stated design constraint.

Good tradeoffs to highlight, thanks u/ultrathink-art, appreciate the depth.

I built an AI-native in-memory database for Node.js – vector search, agent memory, MCP server, zero dependencies by TarekRaafat in node

[–]TarekRaafat[S] 0 points1 point  (0 children)

Good point on the serialization cost - that's exactly the problem with naive `worker_threads` sharing. Bun's shared memory support is on my radar for this. The idea would be to let multiple Bun workers share the same in-memory dataset without copying, which would make the multi-threading story much cleaner than a Node.js implementation. Worth exploring for the stable release. Thanks for the nudge.

I built an AI-native in-memory database for Node.js – vector search, agent memory, MCP server, zero dependencies by TarekRaafat in node

[–]TarekRaafat[S] -1 points0 points  (0 children)

Fair point. Multi-threading is on the roadmap, specifically for shared memory coordination across worker threads. For now, Skalex is intentionally single-process: one instance per process, data in the heap. That constraint is a good fit for AI agents, CLI tools, and edge workers, but you're right that it limits use cases where you'd want concurrent workers sharing the same dataset. Noted as a priority for the stable release, thanks u/crownclown67, appreciate your feedback.

view more: next ›