[GH-ISSUE #273] Native binary storage shows scaling bottlenecks under concurrent realtime workload #118

New issue

Open

opened 2026-05-23 08:31:11 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-23 08:31:11 -06:00

Owner

Originally created by @ismael1361 on GitHub (Apr 17, 2026).
Original GitHub issue: https://github.com/appy-one/acebase/issues/273

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.

Originally created by @ismael1361 on GitHub (Apr 17, 2026). Original GitHub issue: https://github.com/appy-one/acebase/issues/273 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 1. Is there any official recommendation for handling high-concurrency realtime workloads? 2. Can `SQLiteStorageSettings` mitigate this bottleneck in production? 3. 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.