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, AES-256 encryption, 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.

Security

AxioDB prioritizes data security with built-in features to protect your data—whether it's sensitive user info or critical business data.

Encryption

Optional AES-256 encryption for collections. Data is encrypted before being written to disk and decrypted when read, keeping sensitive data protected at rest.

Secure Storage

Data is stored in secure .axiodb files, using a structured format to maintain integrity and prevent unauthorized access or corruption.

InMemoryCache

InMemoryCache improves performance and adds security by reducing disk reads, minimizing exposure of sensitive data.

How AxioDB Secures Your Data

Encrypted at rest and in transit
File-level isolation and locking
Configurable access controls
Automatic cache invalidation for stale data

Implementing Secure Collections

To create a secure, encrypted collection, simply pass the encryption parameter as true and provide a secret key when creating the collection:

// Create an encrypted collection with auto-generated key
const secureCollection = await db1.createCollection(
  "users",
  true        // Enable encryption (key auto-generated)
);

// Create an encrypted collection with custom key
const customKeyCollection = await db1.createCollection(
  "sensitiveData",
  true,       // Enable encryption
  "your-strong-secret-key"  // Custom encryption key
);

Once created, all operations on the collection (insert, query, update, delete) will automatically handle encryption and decryption, making the process transparent to your application.

Control Server Authentication (RBAC)

The Control Server (the built-in web GUI at localhost:27018) ships with login and role-based access control. On first start it seeds a reserved config database (hidden from the regular database list and unreachable through the generic database/collection/document routes) holding three collections - users, roles, and permissions - plus a default admin/admin account.

Password hashing: Node's built-in crypto.scrypt with a random per-user salt - no extra dependency, consistent with AxioDB's zero-native-dependency design.
In-memory sessions only: Sessions live in a server-side memory map, never written to disk. A restart invalidates every session and forces everyone to log in again - this is by design, not a bug.
Cookie is not the trust boundary: The session cookie only carries a random, unguessable session ID; the username/role are looked up server-side from the in-memory session map on every request, not trusted from the cookie itself.
Forced password change: Every account, including the seeded admin, must change its password on first login before any other action is permitted.
Three predefined roles: Super Admin (full access, including user/role management), Admin (full database/collection/document access, no user/role management), and View (read-only). A Super Admin can create additional custom roles from the predefined permission catalogue.

This isn't GUI-only: AxioDBCloud's TCP server reuses this exact same config database, accounts, and roles when started with TCPAuth: true — one login system for both. TCP additionally enforces a shared per-IP rate limiter, rejects still-must-change-password accounts outright, and forces re-authentication on an open connection when an admin changes that user's password/role via the GUI. See AxioDBCloud → Advanced: TCP Authentication for the full enforcement details.

RBAC protects the Control Server's HTTP API and the TCP server alike, but both are still designed for trusted local/network access - not a substitute for network-level protections if you expose either beyond your own machine or private network. The TCP protocol itself is also unencrypted (no TLS).

Security Best Practices

Use strong, unique encryption keys for each sensitive collection
Never hardcode encryption keys in your application code
Consider using environment variables or a secure key management system
Implement proper application-level access controls
Regularly backup your encrypted databases
Keep your AxioDB version updated to benefit from security patches

For reporting security vulnerabilities or concerns, please refer to the SECURITY.md file in the project repository.