# Developer guide to the difference between Ceramic and ComposeDB.
## What is Ceramic?
The Ceramic popularly referred to as the ceramic network is a decentralized network for composable data (data that can be created). The ceramic network makes data composable and makes these composed data available for reuse across all other applications, hence the whole importance of decentralization. Ceramic makes the building of web3 data very easy, it is as easy or simple as searching a store where data models are kept, finding the one that suits your app, plugging it into your application, storing, updating, and retrieving data from those models and even reusing these models.
Ceramic provides developers with a set of open APIs for their database (i.e for storing, updating, and retrieving data from the decentralized network). This makes all data to be open and accessible and helps break the data into smaller units.
As a developer building, a composable application with web3 data on ceramic is simple. Follow these basic steps:
1. Install Ceramic
2. Browse the data model marketplace
3. Select a model and plug it to your application
If you have done this you automatically get access to all the data stored on the network that corresponds with those data models. The Ceramic community is not done yet with creating tools that would make it easier to build with composable data.
## The core parts of the ceramic network are;
1. A Decentralized Data Infastructure That Is Scalable
2. A marketplace for community-created models
3. Open APIs for database management (storage, update, and retrieval of data)

## Decentralized Data Infastructure
The decentralized data structure is highly scalable and as such, every application in the world can build on it. The ceramic network is made up of collections of nodes that work with each other to make data available for all the states stored on the network and reach an agreement about these states anytime there is a new transaction. The ceramic network is not just designed for financial applications like tokens but also for decentralized social networks, decentralized gaming, and even identification system.
## Marketplace
Aside from the fact that Ceramic is decentralized and has an infrastructure for data it also has a very active ecosystem and community members. Data models are a novel abstraction that unifies how similar types of applications store and retrieves state from each individual user on the network. Ceramic takes a community-driven approach to create these data models, allowing any developer to easily define, share, and reuse their models with other developers in the ecosystem. As more data models are created by the community, we will see a continuous expansion in the quantity and variety of applications that are built with composable data
## Open APIs
Finally, what is decentralization if we cannot have open APIs? The whole goal of ceramic is to create a decentralized and permissionless ecosystem for its users, thus it has open APIs for storing, modifying, and retrieving data from the ceramic network.
# The ComposeDB
This is the child to the composite and this is like using the ceramic as a graph network. What the composeDB does is give graph structure for interacting with data on the graph network. The nodes in the graph are accounts while the edge in the graphic represents relations between nodes. ComposeDB does not currently support relations between accounts and documents yet.
ComposeDB supports two types of nodes: accounts that are able to manipulate data in the graph, and documents containing mutable data of a given shape.
### Account
Ceramic uses Decentralized Identifiers (DIDs) for accounts, which get translated to Ceramic Account Objects by the ComposeDB client.
DIDs can represent any entity that is able to write data on Ceramic and therefore in ComposeDB, which can be end-users of an application, groups, applications or any kind of authenticated service.
In order to write data in ComposeDB, a DID must be attached to the ComposeDB client instance, as documented on the [mutations page.](https://composedb.js.org/docs/0.3.x/guides/interacting/mutations)
### Documents
Documents in ComposeDB are [Ceramic streams](https://developers.ceramic.network/learn/advanced/overview/#streams) storing structured data defined by a [model](https://composedb.js.org/docs/0.3.x/first-composite#models).
Ceramic nodes can be configured to index specific models, storing all the documents using a model in a local database in order to provide fast access and query capabilities.
For example, using GraphQL, the ComposeDB client allows to query documents indexed by a Ceramic node, as well as creating new documents and updating existing ones when [mutations are enabled](https://composedb.js.org/docs/0.3.x/guides/interacting/mutations).
### Models
Models are Ceramic streams storing metadata about documents, notably their data structure, validation rules, and relations, as well as discovery information.
ComposeDB tools abstract the creation of models using GraphQL’s Schema Definition Language, as described in the dedicated [documentation page](https://composedb.js.org/docs/0.3.x/guides/creating-composites/schema).