AxioDB is an embedded NoSQL database for Node.js with MongoDB-style queries. It is a pure JavaScript alternative to SQLite with zero native dependencies, no node-gyp compilation, and no platform-specific binaries. Install with 'npm install axiodb' and you have a database — no mongod process, no server setup. Perfect for Electron apps, CLI tools, and local-first applications.

Is AxioDB a replacement for MongoDB?

No. AxioDB is embedded — it runs inside your app with no server. MongoDB is a client-server database for multi-user production systems. Use AxioDB for desktop apps, CLI tools, and local-first applications with 10K–500K documents. Use MongoDB when you need a shared, networked, multi-user database.

Does AxioDB work with Electron?

Yes — Electron is the primary use case AxioDB was built for. Zero native dependencies means no electron-rebuild, no platform-specific .node files, no node-gyp compilation. Just npm install axiodb and it works on Windows, Mac, and Linux without any rebuild step.

What is the difference between AxioDB and better-sqlite3?

better-sqlite3 uses C native bindings and requires compilation via node-gyp. AxioDB is pure JavaScript — it installs in any Node.js environment without compilation or platform-specific builds. AxioDB also uses NoSQL/JSON document queries instead of SQL strings, includes built-in caching and Worker Threads, and works out of the box in Electron without electron-rebuild.

What is the difference between AxioDB and lowdb?

lowdb stores everything in a single JSON file and becomes slow above 1,000–5,000 records due to full-file reads on every operation. AxioDB uses file-per-document tree storage with InMemoryCache, Worker Threads, and auto-indexing — optimized for 10,000–500,000 documents with O(1) lookups by ID and fast filtered queries.

What is the difference between AxioDB and nedb?

NeDB is abandoned (no active maintenance since 2016) and keeps the entire database in memory. AxioDB is actively maintained, uses file-based storage, supports TypeScript, ACID transactions with savepoints and WAL, Worker Threads, custom field indexing, and AxioDBCloud remote access.

How many documents can AxioDB handle?

AxioDB is optimized for 10,000–500,000 documents per collection. For 1M+ documents, migrate to PostgreSQL or MongoDB. AxioDB's InMemoryCache and Worker Threads keep performance fast within this range — documentId lookups take ~1ms and indexed queries take ~2ms on 10,000 documents.

Does AxioDB support TypeScript?

Yes. Full TypeScript type definitions are included out of the box with the axiodb npm package. No @types/axiodb needed.

Does AxioDB work in the browser?

No. AxioDB requires Node.js (v20+) and uses the filesystem for storage. It is a server-side and desktop embedded database. It does not run in browsers.

AxioDBCloud is a TCP-based remote access layer for AxioDB. Deploy AxioDB in Docker or Cloud, then connect from multiple clients using the exact same API as embedded AxioDB — zero code changes. Supports 1,000+ concurrent connections, auto-reconnect with exponential backoff, and heartbeat monitoring.

SEE HOW AXIODB HAS EVOLVED

Changelog

Every major milestone in AxioDB's history, from the very first commit onward. This is a curated list of what actually changed - not every commit or patch bump, just the releases that shipped something meaningful.

v14.1.4

2026-07-25

Transaction durability hardening, single-fsync WAL batching, and 30-char document IDs

•Fixed: a WAL append or .tmp staging-write failure during commit was silently swallowed - appendLog()/WriteFile() return an Error result instead of throwing, so the commit proceeded and mutated a document with no log to recover from. Both are now checked and abort the commit, routing into the existing rollback path.
•Fixed: rollback left orphaned .tmp staging files behind (executeOperations can now throw mid-loop after staging some files); rollback() sweeps them.
•Fixed: rollbackIndexUpdates only discarded the staged map, but stageIndexUpdates mutates the shared in-memory index cache in place (IndexCache.getIndex returns the live object) - a rolled-back transaction left a phantom index entry pointing at a never-written document, causing post-rollback "Failed to read file" noise and wasted reads. Rollback now invalidates the touched index fields so the next read reloads a clean copy from disk.
•Fixed: recoverTransactions is registry-driven and never cleaned WAL files with no registry entry - a crash between createWAL() and registerTransaction() left an orphan .wal that survived recovery (a timing-dependent crash-recovery test failure, seen on Node 21 CI). Recovery now snapshots WAL files at startup and sweeps orphans not tracked by the registry; added a deterministic regression test that plants an orphan WAL.
•Performance: transaction commit now persists all WAL entries in a single fsync'd batch (appendLogBatch) instead of one fsync per operation - a 1000-document insertMany drops from ~1000 WAL fsyncs to 1, roughly 6x faster per document in local benchmarks (~4.5ms/doc to ~0.7ms/doc). Single-document insert is unchanged.
•Auto-generated document IDs are now 30-character uppercase alphanumeric (was 15-character letters-only), lowering collision odds; existing shorter IDs remain valid and readable.

v13.1.3

2026-07-24

Fixed a process-exit hang; added real crash-recovery test coverage

•Fixed: InMemoryCache's background eviction interval had no unref(), so any short-lived script or CLI process using AxioDB (a stated core use case) would never exit on its own without an explicit process.exit() call - it now unrefs the same way IndexCache's cleanup interval already did
•Added a real crash-recovery test suite (npm test crash-recovery): spawns a child process hammering inserts/updates, SIGKILLs it mid-write with no graceful shutdown, then verifies from a fresh process that every recovered document is complete and valid, and the WAL is cleaned up - this is the one guarantee this project had only reasoned about, never actually tested, until now
•Added regression tests for this release's index-reordering fix, the cache-invalidation-scope fix, and the "no match" error contract for UpdateOne/UpdateMany/deleteOne/deleteMany
•Wired the new crash-recovery suite into CI (Push.yml and auto_ci.yml Gate 4, alongside crud/transaction/read); synced the npm test command reference across CLAUDE.md, AGENTS.md, .claude/rules/commands.md, .github/copilot/instructions.md, and the axiodb-development skill, which had all drifted to list only crud/transaction/read

v13.1.1

2026-07-24

Update and delete are now WAL-backed (full ACID coverage)

•UpdateOne/UpdateMany/deleteOne/deleteMany now route through the same Transaction/WAL machinery insert() already used, instead of a separate ad-hoc lock-and-write path
•Fixed: a failed index-sync after a successful document write used to be silently swallowed (fire-and-forget), leaving the index out of sync with no way to recover on crash - it's now staged and committed atomically with the document change, with WAL redo/undo on failure
•Removed the now-redundant per-call LockManager/DocumentLoader-reread/DeleteIndex/InsertIndex wiring from UpdateOperation and DeleteOperation - Transaction already does locking, the fresh re-read under lock, and index staging correctly
•insertMany's earlier index-rewrite batching win (Document/src/data/changelog.ts 13.0.0) now applies to UpdateMany/deleteMany too: one index-file rewrite per affected field for the whole batch, not one per document
•Fixed: TransactionIndexManager.stageIndexUpdates was removing and re-appending a document's file entry in an index bucket even when that field's value hadn't changed, silently reordering the bucket - for documents sharing an indexed value (e.g. duplicate names), this could make a later query's "first match" resolve to a different document than the one just written. It now skips a field's index entirely when its value is unchanged.
•Removed InsertIndex.service.ts and DeleteIndex.service.ts - both were only used by the old ad-hoc update/delete path this release replaced, leaving them with zero live callers; Collection now constructs the shared IndexManager base class directly for createIndex/dropIndex/listIndexes
•Fixed: routing update/delete through Transaction.commit() had it invalidate the whole collection's cache on every write (the behavior insert() always needed) instead of only the affected documents' cache entries - an update to one document was evicting unrelated cached queries that never matched it. commit() now only does the broad invalidation when the transaction contains an INSERT; update/delete-only transactions evict just the specific documents that changed.

v13.0.0

2026-07-24

Encryption removed; sorted-index range queries; batched inserts

•BREAKING: removed per-collection AES-256 encryption (isEncrypted/encryptionKey params on createCollection and every downstream API) - unnecessary overhead for an embedded database; existing encrypted collections will not be readable after upgrading
•CryptoHelper/CryptoGraphy helpers, and every isEncrypted/encryptionKey parameter across Collection, Reader, Update, Delete, Aggregation, Transaction, Session, and the HTTP/TCP APIs, removed
•Range queries ($gt/$gte/$lt/$lte) on indexed fields now resolve via a sorted-value binary search instead of a full collection scan
•insertMany now batches every document into a single Transaction (one index-file rewrite per field instead of one per document) instead of committing a separate Transaction per document
•Fixed: UpdateOne/UpdateMany/deleteOne/deleteMany now re-read the target document under the lock instead of trusting the pre-lock snapshot, closing a lost-update race under concurrent writers
•Fixed: document rewrites during update are now an atomic temp-file-plus-rename instead of delete-then-recreate, so a concurrent unlocked read can no longer observe a transiently missing file
•Fixed: the transaction registry (txn-meta.json) is now fsynced on every write, so recovery can no longer lose track of a committed WAL entry on crash

v12.10.20+

2026-07-12

MCP Server for AI agent integration

•MCP server (Model Context Protocol) added to the Docker image, opt-in via AXIODB_MCP=true, exposing 32 tools over Streamable HTTP on port 27020
•Real login required (axiodb_login) - every tool is gated by the logged-in user's actual RBAC role, mirroring the HTTP Control Server's permissions exactly
•Full coverage: database/collection/document CRUD, aggregation, indexes, dashboard stats, and user/role management (including a new role-deletion capability, added to both the HTTP API and MCP)
•Session tools: axiodb_logout, axiodb_whoami, axiodb_change_own_password
•Fixed: aggregation $sum/$avg crashing on numeric literal operands (e.g. { $sum: 1 })
•Fixed: delete-by-query silently deleting nothing while reporting success when isMany was left unset
•Fixed: total document count including the collection's internal indexes folder in the total
•Fixed: collection metadata responses no longer leak the raw AES encryption key
•Removed dead chmod-based file/directory locking code (LockFile/UnlockFile/IsFileLocked, LockDirectory/IsDirectoryLocked) that was never actually engaged by any internal flow

v11.9.13+

2026-07-11

AxioDBCloud connection pooling, rate limiting & TLS

•Connection pooling for AxioDBCloud with least-busy routing (fewest in-flight requests) instead of round-robin
•Per-IP concurrent connection cap and connection-attempt rate limiting on the TCP server
•TLS/SSL encryption support for TCP connections
•RBAC and TCP Auth test gates added to CI
•SEO metadata integrated across all documentation pages

v9.7.7

2026-07-10

Session-based GUI auth & TCP authentication

•Session-based authentication with cookie support for the Control Server GUI
•TCP authentication (RBAC) and index management commands added to AxioDBCloud

v9.6.1

2026-03-27

AxioDB constructor refactor

•AxioDB constructor refactored to accept a single options object instead of positional arguments

v8.33.235

2026-03-23

ACID compliance milestone & CI matrix testing

•Pseudo-ACID transaction compliance across CRUD operations
•CI test matrix expanded across multiple Node.js versions
•Query optimization in Reader and Searcher classes

v7.33.234

2026-03-15

Path-traversal hardening

•DocumentLoader and PathSanitizer utilities added to centralize safe file handling
•Formal contributor rules and development guidelines added to the repo

v6.33.128

2026-03-13

AxioDBCloud (TCP remote access) begins

•TCP server and ConnectionManager implemented - the foundation of AxioDBCloud remote access
•Protocol error handling and HTTP-vs-TCP-port misconfiguration detection

v6.33.127

2026-03-11

Smarter caching & index cleanup

•Selective cache invalidation and randomized TTL to avoid cache-stampede synchronization
•DeleteIndex service for removing documents from indexes
•IndexCache gained TTL-based expiry and cleanup

v5.33.127

2026-03-10

ACID transactions with Write-Ahead Log

•TransactionIndexManager, TransactionRegistry, and Write-Ahead Log (WAL) services implemented
•Foundation for session-based transactions with commit/rollback

v3.31.104

2025-10-31

Worker-thread performance overhaul

•File processing parallelized with Promise.all across worker threads
•Reader/search operations tuned to use all available CPU cores
•Sorting utility optimized to use native comparison

v2.30.93

2025-08-31

Database export/import

•Database export as a compressed .tar.gz archive
•Database import from an uploaded archive
•Advanced JSON query search support

v2.28.81

2025-08-24

API reference page & transaction tokens

•API reference documentation page added to the Control Server GUI
•Transaction token support added to the HTTP API

v2.28.77

2025-08-20

Dashboard caching & transaction tokens

•Caching and transaction token support for collections and databases
•Dashboard stats retrieval integrated with the cache layer

v2.24.71

2025-08-11

Full CRUD document management UI

•Create, read, update, delete, and aggregate operations added to the Control Server GUI as modal-driven workflows
•Advanced search with JSON query and document-ID lookup in the Documents page

v2.19.65

2025-07-27

Database management UI & JWT key management

•Database management routes/controller and GUI dashboard (Zustand state management)
•JWT-based key management for database instances

v2.18.54

2025-06-23

Engine refactor & worker-based search

•Legacy FileManager/FolderManager replaced by the current engine/ module structure
•HashmapSearch replaced by worker-thread-based Searcher for parallel file reads

v2.13.47

2025-06-21

Control Server (HTTP GUI) foundation

•AxioDB Control Server implemented on Fastify with health check and routes endpoints
•Tailwind CSS integrated into the GUI

v2.11.29

2025-06-14

GUI authentication & schema validation

•JWT-based authentication checks added to the GUI
•Schema validation for user registration and collection data

v2.10.19

2025-06-08

Initial Docker support

•First Docker setup: package.json, tsconfig.json, and a schema generator utility for containerized deployments

v1.5.8

2025-04-02

Cache invalidation on writes

•Cache clearing wired into update and delete operations, and a clearAllCache method added

v1.4.3

2025-03-26

Aggregation pipelines

•aggregate() method added to Collection with MongoDB-style pipeline stages
•$match filtering extended to support regex and object matching

v1.3.9

2025-03-20

Full CRUD operation suite

•Reader class: query, sort, skip/limit pagination, and total-count support
•DeleteOperation: deleteOne and deleteMany with detailed error handling
•UpdateOperation: UpdateOne and UpdateMany with schema-aware partial updates

v1.1.4

2025-02-28

Encryption support

•CryptoHelper class added for AES encryption/decryption of collection data

v1.1.2

2025-02-14

Core Collection & Database classes

•Collection and Database classes implemented - the foundation of the document store
•FileManager/FolderManager error handling improved

v1.0.16

2024-12-25

Initial Web GUI

•First GUI setup with Vite and React, alongside a server-file restructure

v1.0.14

2024-12-23

In-memory caching

•InMemoryCache class added, with TTL-based expiry for cached query results

v1.0.0

2024-12-07

Fastify server & first insert

•Fastify HTTP server integrated into the project
•The `Configuration` class was renamed to `AxioDB`
•First working document insert feature

v1.0.0

2024-10-01

Project inception

•Initial commit: repository scaffolding, FileManager/FolderManager engine, and an initial `Configuration` class (later renamed to `AxioDB`)