Limitations & Scale Considerations

Scale & Performance Boundaries

• Dataset Size: Optimized for 10K-500K documents. For 10M+ documents, use PostgreSQL, MongoDB, or SQLite which are designed for massive scale.
• Disk Usage per Document: AxioDB stores one file per document, and a filesystem allocates whole blocks — typically 4 KB. A 128-byte document therefore occupies 4 KB on disk. Measured on ext4, 20,000 documents of ~130 bytes used 80 MB for 2.6 MB of data (31× amplification). The waste shrinks as documents grow and disappears around 4 KB each, so budget ~4 KB per document when storing many small records. In exchange, documentId lookups are O(1) with no index consulted, and a torn write can only ever damage one document.
• Unindexed Scans: A query that is not a documentId lookup or an exact match on an indexed field reads every document in the collection — one file open per document rather than a single sequential read. On the same 20,000 documents a full scan measured 208 ms against 20 ms for an equivalent single-file format. Index the fields you filter on; the cost grows with collection size.
• Concurrency: Single-instance architecture. For multi-user web applications with hundreds of concurrent connections, use traditional client-server databases.
• Relational Data: Document-based NoSQL architecture. No JOIN operations. For complex relational data with foreign keys and constraints, use SQL databases.
• Distributed Systems: Single-node only. No replication, no sharding, no clustering. For distributed systems, use MongoDB or CouchDB.
• Transactions: No ACID transactions across multiple collections. For transaction requirements, use PostgreSQL or MongoDB with transactions enabled.