AceBase puts a Firebase-style realtime database in your own process

A realtime tree that lives in a file next to your server

AceBase is a NoSQL database engine written in TypeScript that targets the same work Firebase Realtime Database handles: JSON trees, push-style writes, and subscriptions that fire when a value changes. Where it diverges is placement. The default engine keeps everything in a binary file on the local filesystem, so the same database code can run on a NAS, a Raspberry Pi, a developer laptop, or inside a browser tab through IndexedDB. The README states the engine can hold up to 2^48 (281 trillion) object nodes in a binary database file that theoretically grows to a maximum filesize of 8 petabytes. Treat those numbers as a description of the addressable file layout rather than a measured operating point, since no benchmark appears anywhere in the docs. The audience is developers who want realtime database behaviour without paying a hosted service, and teams who want the data to sit on infrastructure they already control.

Four packages, one engine, and separate server concerns

AceBase is not one npm package. The project splits into acebase, the local database engine; acebase-server, a server endpoint that enables remote connections and includes built-in user authentication and authorization plus support for external OAuth providers such as Facebook and Google; acebase-client, the client that connects to an external AceBase server; and acebase-core, the shared functionality the other packages depend on. The main acebase package.json points require at ./dist/cjs/index.js and import at ./dist/esm/index.js, with TypeScript declarations at ./dist/types/index.d.ts, so CommonJS and ESM consumers are both served from a single install. That split matters when you plan a deployment. A service that keeps its data in process needs only acebase. An app in a browser talking to a shared backend needs acebase-client and a running acebase-server, which adds the authentication layer you did not have to think about in the local case.

Installing the engine and opening your first database

The local engine installs like any other dependency from npm. Opening a named database then takes two statements, and the second one is the interesting half because it selects the storage location by constructor rather than by configuration file. Use this for a server side database:

npm install acebase

const { AceBase } = require('acebase');
const db = new AceBase('my_db'); // nodejs

The README shows the same setup with a db.ready callback, which is the point at which the engine has opened its file and its index structures and reads and writes become safe. The browser variant swaps the constructor, and the package browser field in package.json redirects the binary, promise-fs, ipc, sqlite and mssql modules to browser specific builds, so the same API surface survives the move to IndexedDB. The docs also send you to RunKit to try the engine without any local install. What the visible documentation does not give you is a production deployment recipe for the server package.

Indexes, schemas and geo queries go past the Firebase baseline

Several parts of the feature set reach beyond what the reference product offers, and they are the reasons an engineer might pick this engine. The docs describe indexes that can be built with wildcards for scattered data, extra fields stored alongside a key, array indexes, fulltext indexes and geo indexes. Queries can be limited, counted, checked for existence, streamed, and run in a realtime variant, and a query can also remove the data it matches. On top of that, schemas arrived in v1.3.0 to validate data and enforce rules, and a class mapping layer loads stored records into your own classes. There is a Reflect API for inspecting node metadata and children, an export and import path for moving data in and out, and a transaction logging feature. These are documented as capabilities with headings in the table of contents, though the visible text gives each only a short description rather than a worked example.

Storage is pluggable, and the alternative backends are not clones

The default storage engine writes a binary file, and the docs also describe SQLite and MSSQL backends, a CustomStorage interface for building your own, and the IndexedDB path used in browsers. The browser mapping in package.json makes the shape of the trade-off visible, because it swaps the binary, promise-fs, ipc, sqlite and mssql modules for browser builds rather than removing them, so callers keep one API. The trade-off sits underneath that convenience. The alternative backends are separate engines rather than mirrors of the default one, and the documentation does not set out which operations, which index features or which transactional guarantees behave identically across them. If you expect to start on the binary file and migrate to SQLite or MSSQL later, that gap is the first thing worth testing, because a feature that only works on the default engine would leave you rewriting storage code at the worst possible moment.

Subscriptions, wildcard paths and the live data proxy

Realtime support is the reason most people arrive, and the docs cover it in more depth than the rest of the feature list. Subscriptions attach to paths, and paths can contain variables and wildcards so that one subscription covers many nodes. There is a notify-only mode for change events, an option to wait for events before a subscription activates, and a mutated and mutations pair that tracks which fields actually changed rather than merely that something changed. An observe mode covers plain value changes, and the live data proxy, which the README highlights, lets code read and write live database values through in-memory objects with no extra database coding. A separate TypeScript section for proxy methods suggests typed access is treated as a first-class concern. The wildcard and variable paths are the part most likely to catch you out, because a broad subscription turns every write beneath that path into an event your handler has to filter.

What the documentation leaves unsaid

Several gaps show up without reading any source code. The README is long and feature dense, but for most features it offers a heading and a sentence rather than a worked example, and the transaction logging, multi-process support and export sections appear as headings in what is visible. No rollback, backup or restore procedure is described, and the recovery story for a damaged binary file is not spelled out. The multi-process section exists in the table of contents, which tells you the topic is considered, but it does not tell you whether concurrent writers from several processes are safe, coordinated, or unsupported. The licence is MIT, so redistribution and modification are permissive, yet MIT carries no warranty and creates no support obligation for anyone who runs this in production.

Release pace, semver promises and the cost of an upgrade

Maintenance is visible and recent. The last push was on 2026-06-25, and the three most recent releases are v1.29.13 on 2026-06-25, v1.29.12 on 2026-06-08 and v1.29.11 on 2026-05-12. The project states that it uses semver versioning to prevent breaking changes from affecting older code, and the version numbers show a stable 1.x line with no major bump in view. For the local engine that keeps upgrade cost modest: bump the dependency and recheck anything that touches schemas or indexes. The catch is that the four packages are versioned separately and share code through acebase-core, so pinning acebase while leaving acebase-client or acebase-server on a different release line can pull mismatched shared code into one application. Pin all of them to the same line and re-test subscriptions after each bump.

Editorial conclusion

Adopt AceBase when you want Firebase-style realtime trees and query support but need the database to run inside your own process or on your own hardware, and can accept a single binary file as the storage model. Do not adopt it if you need a managed service, a documented backup and restore procedure, or a support contract, because none of those appear in the docs. Verify first that your query and index patterns behave acceptably against the binary engine, and confirm that the acebase, acebase-client and acebase-server versions you pin come from the same release line, since the last push was on 2026-06-25 and the shared acebase-core package moves separately.

Frequently asked questions

Official sources

1. appy-one/acebase on GitHub
2. Issues
3. License: MIT
4. README
5. Releases