Overview

Comparisons

vs plain JSON files#

Traditional JSON files AxioDB
Single JSON file — heavy read/write I/O File-per-document storage
No built-in caching InMemoryCache strategy
Linear search for document retrieval Auto-indexed documentId for fast lookups
Performance degrades with dataset size Maintains performance at scale
No indexing system Multi-core parallelism with Worker Threads
Manual file locking for concurrency Built-in query operators ($gt, $lt, $regex, $in)

vs SQLite#

Feature SQLite AxioDB
Native dependencies Yes (C bindings) Pure JavaScript
Query language SQL strings JavaScript objects
Schema migrations Required (ALTER TABLE) Schema-less (optional)
Built-in caching Manual InMemoryCache
Multi-core processing Single-threaded Worker Threads
Built-in GUI External tools only Web interface included
Best for 10M+ records, relational data 10K-500K documents, embedded apps

Document retrieval speed#

AxioDB's file-per-document architecture with InMemoryCache gives instant document retrieval by ID — O(1) with cache, versus a linear O(n) scan for plain JSON files. Unlike SQLite, there's no native dependency to compile or ship.

When AxioDB is not the right choice#

  • 10M+ documents, or datasets that need to scale past a single node — use PostgreSQL, MongoDB, or SQLite.
  • Multi-user web applications with hundreds of concurrent connections — AxioDB is single-instance, not client-server (though AxioDBCloud adds remote TCP access for service-to-service use).
  • Relational data with JOINs and foreign-key constraints — AxioDB is document-based NoSQL.
  • Distributed systems needing replication, sharding, or clustering — AxioDB is single-node only.
  • Cross-collection ACID transactions — AxioDB's transactions are scoped to a single collection.

AxioDB isn't competing with PostgreSQL or MongoDB — it's for when you need a database embedded in your app, and migrating out when you outgrow it is the expected path, not a failure.

Updated

Was this page helpful?