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.

Should I switch from LowDB to AxioDB?

Yes, if your project has grown beyond prototypes. LowDB has no concurrency safety (concurrent writes corrupt data), no ACID transactions (crash = data loss), no built-in caching, and the entire database is loaded into memory. AxioDB provides file-per-document storage, ACID transactions, InMemoryCache, Worker Threads, and is actively maintained.

Is NeDB still safe to use?

No. NeDB has been abandoned since 2016 with no security patches or bug fixes. Users report data loss and file corruption. For new projects, use AxioDB which provides the same MongoDB-like API with active maintenance, ACID transactions, TypeScript support, and modern features like Worker Threads and built-in GUI.

Why not use better-sqlite3 for Electron apps?

better-sqlite3 requires native C compilation via node-gyp and electron-rebuild for every Electron update. This causes platform-specific build failures and NODE_MODULE_VERSION mismatch errors. AxioDB is pure JavaScript — zero native dependencies means no compilation, no electron-rebuild, and no platform-specific binaries. Install with npm install axiodb and it works everywhere.

What is the best embedded database for Electron apps in 2026?

AxioDB is the best choice for Electron apps in 2026. It has zero native dependencies (no electron-rebuild), ACID transactions, built-in InMemoryCache, Worker Threads for multi-core processing, a built-in web GUI dashboard, and TypeScript support. It handles 10K-500K documents with O(1) lookups by ID and fast indexed queries.

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 even at 100,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 AxioDB's own TCP remote-access layer on port 27019 — a protocol and client, not a hosted service. You run the server yourself with new AxioDB({ TCP: true }) or the Docker image, then connect from other processes using the exact same API as embedded AxioDB, with zero code changes. There is no account to create and Nexoral hosts no database for you. Limits: 1,000 total concurrent connections, 100 per IP. Optional shared-RBAC authentication (TCPAuth) and optional TLS.

How do I replace SQLite with AxioDB in a Node.js project?

Install with 'npm install axiodb' and map concepts directly: a SQLite table becomes a collection, a row becomes a JSON document, INTEGER PRIMARY KEY becomes the auto-generated documentId, CREATE INDEX becomes collection.newIndex('field'), and BEGIN/COMMIT/ROLLBACK become collection.beginTransaction()/.commit()/.rollback(). SQL strings become JavaScript objects: SELECT * FROM users WHERE age > 25 becomes users.query({ age: { $gt: 25 } }).exec(). There are no schemas and no migrations. What you give up: JOINs, foreign keys, SQL itself, ORMs like Prisma and Drizzle, and scale beyond roughly 500,000 documents per collection.

Does AxioDB need node-gyp, electron-rebuild, or a build step?

No. AxioDB is pure JavaScript with zero native dependencies — there is no C code, no .node binary, no node-gyp compilation, and no electron-rebuild step. Nothing has to match your OS, CPU architecture, or Node/Electron ABI version, so NODE_MODULE_VERSION mismatch errors are impossible. 'npm install axiodb' is the entire installation on every platform and every Node.js version 20 or newer.

How do I use AxioDB in an Electron app?

Create the AxioDB instance in Electron's main process only, storing data in the per-user data directory: new AxioDB({ RootName: 'AppData', CustomPath: app.getPath('userData'), GUI: false }). Never write inside the app bundle or app.asar — asar is read-only and app contents are replaced on update. Expose database operations to the renderer through ipcMain.handle plus contextBridge rather than enabling nodeIntegration. No electron-rebuild step and no packaging configuration for native modules is required.

Does AxioDB have an MCP server for AI agents?

Yes — 43 MCP tools covering databases, collections, documents, aggregation, indexes, dashboard stats, user/role management, and transactions. Important: the MCP server ships only in the Docker image theankansaha/axiodb, not in the npm package. Enable it with AXIODB_MCP=true and connect over Streamable HTTP at http://localhost:27020/mcp. Every tool except axiodb_login requires a sessionId from logging in, and destructive tools ask the human for confirmation through the MCP client first.

What ports does AxioDB use?

Port 27018 is the web Dashboard and its REST HTTP API, enabled with GUI: true. Port 27019 is the AxioDBCloud TCP server, enabled with TCP: true — it is a custom TCP protocol, not HTTP. Port 27020 is the MCP server, available only in the Docker image with AXIODB_MCP=true. Ports 27018 and 27019 are not configurable in code; remap them at the Docker layer. Only the MCP port can be changed, via AXIODB_MCP_PORT. By default the embedded library opens no ports at all.

Does AxioDB support MongoDB update operators like $inc and $set?

No. AxioDB updates are a flat shallow merge of your data object onto the existing document. Writing .UpdateOne({ $inc: { balance: -100 } }) does not increment anything — it literally stores a field named '$inc'. To change a numeric value, read the document, compute the new value in JavaScript, and write it back. Query operators are a separate thing and are fully supported: $gt, $gte, $lt, $lte, $eq, $ne, $in, $nin, $exists, $regex, $not, $type, $size, $all, $elemMatch, $or, $and, and $nor.

What are AxioDB's limitations?

AxioDB targets 10,000 to 500,000 documents per collection on a single node. It has no JOINs, no foreign keys, no SQL, no replication, no sharding, and no clustering. Transactions are scoped to one collection — there are no cross-collection transactions. Only one AxioDB instance may exist per process. Aggregation supports only $sum and $avg accumulators, and its $match stage accepts fewer operators than query() does. Queries that are not an exact match on an indexed field fall back to a full collection scan. It does not run in browsers.

Benchmarked13/13 Passing

Performance Benchmarks

Full test suite results at 100,000 documents — CRUD, queries, transactions, HTTP API, TCP, crash recovery, and MCP. Every number from npm test.

AMD Ryzen 5 5500U6C / 12T @ 2.1 GHz7.1 GB DDR4Ubuntu Linux 6.8.0Node v26.8.1September 5, 2026

Indexed Query

1-2 ms

Constant across all sizes

Doc ID Lookup

<1 ms

Direct file-per-doc read

Cache Hit

<1 ms

In-memory cached result

Test Coverage

278 tests

13 suites, all passing

Test Suite Overview

All 13 test suites at 100K documents. Each suite runs in an isolated child process.

CRUD Operations30 tests

3.7 s

Transactions22 tests

625 ms

Read / Query40 tests

146.8 s

Aggregation50 tests

458 ms

Auth & RBAC32 tests

6.0 s

HTTP API38 tests

1.5 s

TCP Auth20 tests

2.7 s

TCP No-Auth6 tests

627 ms

TCP Transactions17 tests

1.4 s

TCP TLS3 tests

641 ms

Crash Recovery3 tests

5.7 s

MCP Confirm11 tests

40 ms

MCP Functional6 tests

1.7 s

Query Scaling (1K - 100K)

How read operations scale across dataset sizes. All timings in milliseconds.

Dataset	Indexed	Doc ID	$gt	$gte/$lte	$in (5)	$in (50)	Limit 5	Regex	Sort	Full Scan
1K docs	1 ms	<1 ms	61 ms	50 ms	41 ms	76 ms	73 ms	79 ms	57 ms	72 ms
5K docs	2 ms	<1 ms	97 ms	89 ms	55 ms	235 ms	173 ms	229 ms	105 ms	241 ms
10K docs	1 ms	1 ms	174 ms	111 ms	85 ms	455 ms	267 ms	466 ms	171 ms	333 ms
50K docs	2 ms	1 ms	657 ms	631 ms	251 ms	1,278 ms	1,111 ms	1,150 ms	760 ms	1,050 ms
100K docs	1 ms	1 ms	1,123 ms	807 ms	533 ms	2,047 ms	1,709 ms	1,959 ms	1,217 ms	1,781 ms

Speed:Lightning (≤2 ms)Fast (≤100 ms)Moderate (≤300 ms)Slow (≤1 s)Heavy (>1 s)

Scaling Behavior

How each query operation scales from 1K to 100K documents.

IndexedExact match on indexed field

1 ms

2 ms

10K

1 ms

50K

2 ms

100K

1 ms

Doc IDDirect documentId lookup

<1 ms

10K

1 ms

50K

1 ms

100K

1 ms

$gtGreater-than range scan

61 ms

97 ms

10K

174 ms

50K

657 ms

100K

1,123 ms

$gte/$lteCombined range boundary

50 ms

89 ms

10K

111 ms

50K

631 ms

100K

807 ms

$in (5)In-operator, 5 values

41 ms

55 ms

10K

85 ms

50K

251 ms

100K

533 ms

$in (50)In-operator, 50 values

76 ms

235 ms

10K

455 ms

50K

1,278 ms

100K

2,047 ms

Limit 5Small limit query

73 ms

173 ms

10K

267 ms

50K

1,111 ms

100K

1,709 ms

RegexPattern matching

79 ms

229 ms

10K

466 ms

50K

1,150 ms

100K

1,959 ms

SortSorted range query

57 ms

105 ms

10K

171 ms

50K

760 ms

100K

1,217 ms

Full ScanCollection scan (10K cap)

72 ms

241 ms

10K

333 ms

50K

1,050 ms

100K

1,781 ms

Operation Breakdown

Individual operation timings from every test suite at 100K documents.

CRUD Operations

Insert Single1 document

31 ms

InsertMany (500 docs)batch insert

365 ms

Find by Indexexact match

3 ms

Find by documentIddirect lookup

<1 ms

Find $gtrange scan

55 ms

Find $inset lookup

2 ms

Find $ne / $ninnegation

56 ms

Find Limit/Skip/Sortpagination

70 ms

findOnefirst match

<1 ms

Update Single1 document

35 ms

Update Multiplebatch update

326 ms

Delete Single1 document

28 ms

Delete Multiplebatch delete

144 ms

Transactions (ACID)

Insert + Commit

38 ms

Update + Commit

32 ms

Delete + Commit

44 ms

Mixed Operations

46 ms

Rollback

8 ms

Savepoint Create + Rollback

24 ms

withTransaction (auto-commit)

21 ms

Index sync after commit

20 ms

HTTP API Endpoints

POST /auth/login

92 ms

PATCH /auth/change-password

127 ms

GET /db/databases

35 ms

POST /db/create-database

2 ms

POST /operation/create/

35 ms

GET /operation/all/by-id/

3 ms

POST /operation/all/by-query/

12 ms

PUT /operation/update/by-id/

26 ms

DELETE /operation/delete/by-id/

29 ms

POST /operation/create-many/

31 ms

POST /operation/aggregate/

4 ms

GET /dashboard-stats

34 ms

TCP / AxioDBCloud

Auth + CRUDauthenticated

40 ms

Connection Pool (10)pool init

184 ms

Custom Pool Sizepool init

84 ms

TLS CRUDencrypted

93 ms

Rate Limit Lockoutper-IP

101 ms

Disconnect Auto-Rollbacksafety

509 ms

Index Hint via TCPquery hint

82 ms

Crash Recovery

SIGKILL during insertsrecovers cleanly

1,722 ms

SIGKILL during updatesvalid before/after

1,936 ms

SIGKILL during indexed insertsindex consistent

2,030 ms

MCP Server (AI)

DB / Collection / Document

214 ms

Transaction handlers

7 ms

User / Role / Dashboard

889 ms

Key Takeaways

Indexed = O(1) constant time

Indexed and documentId lookups stay at 1-2 ms whether the collection has 1K or 100K docs. Each lookup reads exactly one file from disk.

ACID transactions stay fast

Single-operation transactions (insert/update/delete + commit) complete in 32-44 ms. Rollback is just 8 ms.

HTTP API is lightweight

CRUD via HTTP endpoints adds minimal overhead — insert is 35 ms, read by ID is 3 ms, query is 12 ms.

Cache eliminates repeat reads

First query hits disk; subsequent identical queries return from InMemoryCache in under 1 ms. Random TTL between 5-15 minutes.

TCP with connection pooling

10-connection pool initializes in 184 ms. TLS CRUD adds encryption overhead but stays under 100 ms per operation.

Crash-safe recovery

SIGKILL during rapid writes recovers cleanly — no corrupted documents. Recovery scans WAL + registry in ~2 seconds.

Full scan scales linearly

From 72 ms at 1K to 1,781 ms at 100K — linear scaling expected for file-per-document scans.

$in uses Set O(1) lookup

Set-optimized $in at 100K: 2,047 ms for 50 values. The value array is converted to a Set for constant-time checks.

MCP for AI agents

Full MCP server handles DB/collection/document/transaction/user/role operations. Functional tests complete in 1.7 seconds.

Methodology

Each dataset size runs the full npm test suite — 13 test suites in isolated child processes

Timings captured from real test output logs — end-to-end execution including index lookup, file I/O, and filtering

Data generated with fixtures.generateUsers(N) — names, emails, ages (20-69 cycling), consistent across all sizes

Indexes created on name, email, and age fields before dataset insertion

File-per-document storage with JSONL registries, dual-write indexes, and random TTL cache (5-15 min)

No warm-up runs discarded — first-run timings included, reflecting real cold-start behavior