Hello,
I would like to report a scalability issue observed while using AceBase with the native binary storage backend in a realtime production-like environment.
According to the documentation, AceBase provides a native binary storage engine by default, supports IPC for multi-process access, and also allows custom storage implementations such as SQLite and SQL Server via CustomStorage.
Environment
- AceBase using native binary storage
- Node.js realtime application
- High frequency read/write operations
- Realtime chat-like workload with concurrent active users
Issue Description
After reaching approximately 200 registered users, the system was no longer able to consistently register new accounts.
Additionally, when AceBase is used in a realtime chat environment with many simultaneously active users, a significant write/process bottleneck appears, suggesting that the native binary storage backend cannot sustain vertical scaling under this concurrency level.
Expected Behavior
- User registration should continue to operate reliably as the number of users grows
- Realtime operations should maintain acceptable performance under concurrent load
- The storage backend should support vertical scaling without severe throughput degradation
Actual Behavior
- New user registrations become unreliable after around 200 users
- The native binary storage becomes a bottleneck under concurrent workloads
- The application performance degrades significantly in a realtime multi-user environment
Impact
This limitation makes the native binary storage backend unsuitable as the primary persistence layer for scalable realtime systems such as chat applications.
While the database may theoretically support large data volumes, the observed concurrency bottleneck prevents practical vertical scalability under moderate realtime load.
Questions
- Is there any official recommendation for handling high-concurrency realtime workloads?
- Can
SQLiteStorageSettings mitigate this bottleneck in production?
- Is there an official or recommended path for integrating PostgreSQL as a storage backend?
From the documentation, it appears technically possible to implement PostgreSQL support via CustomStorage, but there does not seem to be an official adapter available. The documentation also mentions that multiple processes require IPC coordination to safely access the same database.
Hello,
I would like to report a scalability issue observed while using AceBase with the native binary storage backend in a realtime production-like environment.
According to the documentation, AceBase provides a native binary storage engine by default, supports IPC for multi-process access, and also allows custom storage implementations such as SQLite and SQL Server via
CustomStorage.Environment
Issue Description
After reaching approximately 200 registered users, the system was no longer able to consistently register new accounts.
Additionally, when AceBase is used in a realtime chat environment with many simultaneously active users, a significant write/process bottleneck appears, suggesting that the native binary storage backend cannot sustain vertical scaling under this concurrency level.
Expected Behavior
Actual Behavior
Impact
This limitation makes the native binary storage backend unsuitable as the primary persistence layer for scalable realtime systems such as chat applications.
While the database may theoretically support large data volumes, the observed concurrency bottleneck prevents practical vertical scalability under moderate realtime load.
Questions
SQLiteStorageSettingsmitigate this bottleneck in production?From the documentation, it appears technically possible to implement PostgreSQL support via
CustomStorage, but there does not seem to be an official adapter available. The documentation also mentions that multiple processes require IPC coordination to safely access the same database.