RxDatabase - The Core of Your Realtime Data | RxDB

An RxDatabase Object contains your collections and handles the synchronization of change events.
The database is created by the asynchronous .createRxDatabase() function of the core RxDB module. It has the following parameters:
The database name is a string which uniquely identifies the database. When two RxDatabases have the same name and use the same RxStorage, their data can be assumed as equal and they will share events between each other. Depending on the storage or adapter this can also be used to define the filesystem folder of your data.
When you deploy your app to a staging area, prefix the database name with the staging id. Browser storages like IndexedDB, OPFS, and localStorage are scoped to the origin and not to the URL path. Let's say your app lives on example.com and you have a feature preview at example.com/commit-42/. Both deployments run on the same origin, so with the same database name the preview reads and writes the stored data of the production app. This can corrupt data when the preview uses a different schema version or stores test documents. To fix this, use commit-42-mydatabasename as name for the preview.
RxDB works on top of an implementation of the RxStorage interface. This interface is an abstraction that allows you to use different underlying databases that actually handle the documents. Depending on your use case you might use a different storage with different tradeoffs in performance, bundle size or supported runtimes.
There are many RxStorage implementations that can be used depending on the JavaScript environment and performance requirements. For example you can use the LocalStorage RxStorage in the browser or use the MongoDB RxStorage in Node.js.
(optional) If you want to use encrypted fields in the collections of a database, you have to set a password for it. The password must be a string with at least 12 characters.
Read more about encryption here.
(optional=true) When you create more than one instance of the same database in a single javascript-runtime, you should set multiInstance to true. This will enable the event sharing between the two instances. For example when the user has opened multiple browser windows, events will be shared between them so that both windows react to the same changes. multiInstance should be set to false when you have single instances like a single Node.js process, a React Native app, a Cordova app or a single-window Electron app which can decrease the startup time because no instance coordination has to be done.
Optimizes observed and recurring queries with the EventReduce algorithm. true uses the default options. Set eventReduce: false to disable it, or pass an object to configure it, like the size of the result window buffer. See EventReduce for all options.
(optional=false) If you create multiple RxDatabase-instances with the same name and same adapter, it's very likely that you have done something wrong. To prevent this common mistake, RxDB will throw an error when you do this. In some rare cases like unit-tests, you want to do this intentionally by setting ignoreDuplicate to true. Because setting ignoreDuplicate: true in production will decrease the performance by having multiple instances of the same database, ignoreDuplicate is only allowed to be set in dev-mode.
Closes all other RxDatabase instances that have the same storage+name combination.
By default, RxDB will use crypto.subtle.digest('SHA-256', data) for hashing. If you need a different hash function or the crypto.subtle API is not supported in your JavaScript runtime, you can provide your own hash function instead. A hash function gets a string, ArrayBuffer, or Blob as input and returns a Promise that resolves a string. When a Blob is received (for attachment digest hashing), convert it to a string or ArrayBuffer before hashing.
If you get the error message TypeError: Cannot read properties of undefined (reading 'digest') this likely means that you are neither running on localhost nor on https which is why your browser might not allow access to crypto.subtle.digest.
(optional, default: 0 = disabled)
Groups write-triggered live query updates to limit how often RxDB re-evaluates queries during write bursts. See liveQueryUpdateThrottleTime for full documentation.
Calling this will return an RxJS Observable which streams all write events of the RxDatabase.
Creates a JSON export of every piece of data in every collection of this database. Needs the json-dump plugin. Read more
An export can also be opened read-only in the database viewer, which is useful when you cannot reach the device that runs the database.
Imports a previously exported JSON dump back into the database. The collections have to be created before. Read more
Writes the current (or ongoing) database state to the filesystem. Read more
Returns a Promise which resolves when the RxDatabase becomes elected leader.
Returns a promise which resolves when the database is in idle. This works similar to requestIdleCallback but tracks the idleness of the database instead of the CPU. Use this for semi-important tasks like cleanups which should not affect the speed of important tasks.
Closes the database's object instance. This is to free up memory and stop all observers and replications. Returns a Promise that resolves when the database is closed. Closing a database will not remove the database's data. When you create the database again with createRxDatabase(), all data will still be there.
Wipes all documents from the storage. Use this to free up disk space.
You can also clear a database without removing its instance by using removeRxDatabase(). This is useful if you want to migrate data or reset the user's state by renaming the database. Then you can remove the previous data with removeRxDatabase() without creating a RxDatabase first. Notice that this will only remove the stored data on the storage. It will not clear the cache of any RxDatabase instances.
Pass the same RxStorage that was used to create the