Cowrie Research

composedb

3 min read

ComposeDB

  • Name: ComposeDB
  • URL: https://composedb.js.org/
  • Category: Ceramic sub-protocol / composable graph-database layer / shared data-model and query infrastructure
  • Summary: ComposeDB is Ceramic’s schema, indexing, and GraphQL layer. The useful point is not decentralized database marketing. It is that nodes choose which models to index and applications converge on whichever composites and query endpoints become standard.
  • What it does:
    • Gives developers a GraphQL-based way to read and write application data on top of Ceramic rather than working directly with lower-level event-stream primitives
    • Uses Composites and reusable data models to define app schemas, relationships, and interoperability surfaces
    • Requires nodes to back ComposeDB with a SQL database such as SQLite or Postgres for indexing and query construction
    • Lets apps discover, create, share, and reuse models so different applications can interoperate through common schemas rather than bespoke integrations
    • Pairs with wallet-auth and session tooling through capability-scoped permissions so writes can be limited to specific composites or models
    • Ships as a reference implementation and tooling stack including client, CLI, and developer libraries in the js-composedb monorepo
  • Key claims:
    • The official landing page and docs describe ComposeDB as a decentralized, composable graph database built on Ceramic for interoperable web3 applications, which is the cleanest high-level classification.
    • The Ceramic blog post makes the most important architectural move explicit: each node must choose which models to index into its SQL database. That means practical authority sits partly with indexing decisions and model adoption, not just with Ceramic’s underlying signed-event substrate.
    • The Composite abstraction is the key reusable primitive because it turns many lower-level data models into an application-shaped schema that can also be shared with other apps.
    • GraphQL matters analytically because it packages Ceramic data into a familiar application-query surface. ComposeDB therefore acts as the layer that turns open authenticated data into developer-usable state.
    • The model-reuse thesis is especially relevant for crypto-social and identity systems: interoperability depends less on universal chain consensus than on whether developers converge on the same schemas and composite definitions.
    • The capability/session material is important because permissions can be scoped to particular models. In practice, write authority is shaped by wallet/session tooling and schema boundaries rather than by a single all-or-nothing account permission.
    • ComposeDB belongs in the corpus as a distinct sub-protocol because folding it into Ceramic alone would hide the higher-level control plane where schema design, indexing choice, and query surfaces become the real source of application power.
  • Whitepaper: No canonical standalone ComposeDB whitepaper surfaced in this pass. The strongest primary materials were the official docs, the js-composedb repository, and Ceramic’s official ComposeDB architecture post; see ../whitepapers/composedb-primary-sources-2026-05-10.md.
  • Sources:

Internal linkages

  • Best comparisons: ceramic for the substrate beneath it, tableland for the shared-schema contrast, and the-graph for the query-surface comparison.

Control surface

  • The leverage is not onchain. It sits in model design, composite adoption, SQL-backed indexing scope, and which GraphQL endpoints become the de facto public interface.

  • So treat ComposeDB as a schema-and-query control plane on top of ceramic, not as a protocol with its own hard settlement layer.

  • Last reviewed: 2026-05-26 UTC

Graph View

Backlinks