> For the complete documentation index, see [llms.txt](https://dev.teaproject.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev.teaproject.org/z_glossary/orbitdb.md).

# OrbitDb

[OrbitDb](https://orbitdb.org/) is a Peer-to-Peer Database for the Decentralized Web

> [OrbitDB](https://github.com/orbitdb/orbit-db) is a serverless, distributed, peer-to-peer database. OrbitDB uses [IPFS](https://ipfs.io/) as its data storage and [IPFS Pubsub](https://github.com/ipfs/go-ipfs/blob/master/core/commands/pubsub.go#L23) to automatically sync databases with peers. It’s an eventually consistent database that uses [CRDTs](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) for conflict-free database merges making OrbitDB an excellent choice for decentralized apps (dApps), blockchain applications, and offline-first web applications.

In the TEA Project, every [hosting\_cml](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/hosting_cml.md) has an OrbitDb instance running **outside** of the enclave.

OrbitDb is used to store large data blobs. OrbitDb provides limited non-relational database features but at a much lower cost. For a relational database, developers can use [gluesql](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/gluesql.md). For more essential account balance (money) data, we'd suggest using [state](/z_glossary/state.md) instead.

## Privacy protection

IPFS is open to the public. Anything stored in the IPFS can be accessed by anyone. OrbitDB is no exception. How do we protect the data in the OrbitDB? We use the [app\_aes\_key](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/app_aes_key.md)

The data used in one applicaiton is encrypted using this application AES key inside enclave. When the data is saved to the OrbitDB, it has been encrypted. It will be decrypted when again loaded into the enclave by the same application. Other application cnanot decrypt because they do not have such [app\_aes\_key](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/app_aes_key.md).

The [app\_aes\_key](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/app_aes_key.md) is stored inside the [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md) which is consider the top security of the whole TEA Project network. When a new applicaiton host instance starts, it will request such a AES key to the state machine. After a restricted scurity check, the instance can receive such AES key. Because the AES key only live inside enclave (both state machine or hosting nodes.), it is unknown to outside world.

## Sync

For every TApp, there are multiple hosting nodes. Every node has their own OrbitDB instance running inside the node (outside of the [enclave](/z_glossary/enclave.md)). They sync with each other using the standard OrbitDB sync algorithm. Please visit [orbitdb.org](https://orbitdb.org) for more details on the sync method.

Because all of these instances share the same [app\_aes\_key](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/app_aes_key.md), the data is the same across all nodes as they take advantage of the duplication provided by IPFS/OrbitDB.

## Cost

Since OrbitDB lives outside of the [enclave](/z_glossary/enclave.md) and is stored on a hard disk (actually IPFS), using it would be much cheaper compared to the [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md) (whose data stays inside the RAM of the [enclave](/z_glossary/enclave.md)). Of course, the state machine would be a much more limited resource and be much more expensive than hard disk space outside of the enclave.

## Eventual consistency

OrbitDB provides [**eventual consistency**](https://en.wikipedia.org/wiki/Eventual_consistency), which means you could get temporary inconsistency across all nodes. Your TApp has to handle this possible scenario in its business and UI logic.

If your data is very time sensitive and requires [**strong consistency**](https://en.wikipedia.org/wiki/Strong_consistency), please use the more expensive [state machine](https://github.com/tearust/t-rust/blob/master/docs/_gitbook-dev-docs/z_glossary/state_machine.md) instead.