The Introduction of BlockSuite and Database Block

BlockSuite is positioned as a local-first, block-based application framework built around CRDT state management—aiming to make rich collaborative editing feel as simple as working with local data, while also unlocking new ways to structure content. The core shift is that BlockSuite treats every update as an incremental, conflict-resilient operation, then layers a provider-based database backend on top so state changes can be stored locally or synced to the cloud without forcing developers to adopt complex editor-specific transformation models.

At the heart of the architecture is a CRDT data model (built on Yjs). CRDT records the full history of operations and automatically resolves conflicts during real-time collaboration. That design removes the need to learn framework-specific concepts like transformation commands or serialized action formats that many collaborative editors require for undo/redo. Instead, BlockSuite exposes simple block-level APIs—add, update, and delete blocks—so editing becomes closer to manipulating a list or map. Because CRDTs have stable serialized formats and can encode partial updates, changes can be distributed efficiently across network and local storage, with the underlying provider handling the I/O details.

BlockSuite also changes how rich text is modeled. Traditional editors often rely on a single contenteditable region, which limits control over how the browser mutates the DOM and makes it harder to implement consistent, block-level collaboration. BlockSuite replaces that approach with many discrete text blocks: a document becomes a collection of blocks (e.g., one per paragraph), and each block is a standalone text editor instance that only handles text. Non-text elements like images and tables no longer need to be embedded inside a contenteditable container, because the block store can manage them as separate block types.

That block store is a prerequisite for the architecture, and it enables both performance and extensibility. The editor logic inside each text block can stay small, which makes it feasible to build a custom text editor called “Virgo” quickly and iterate on it independently of the rest of the system. For extensibility, BlockSuite defines blocks using web components, so third-party blocks can be built with any UI framework by packaging them as web components. It also supports multiple “container blocks” so the same underlying data can be presented in different layouts and selection states—enabling collaborative apps like kanban boards, documents, or forms that share a common model but differ in view.

Rendering is treated as modular too. Instead of requiring a DOM-based renderer, BlockSuite includes an experimental canvas renderer for whiteboards, where the top-level canvas view is driven by block state. Finally, the framework’s direction extends beyond editing: a prototype “Database Block” is introduced. It can convert regular blocks (paragraphs, lists, etc.) into database-ready blocks, transform between “Virgo” and database representations, and preserve column information across the workspace. It also supports switching among multiple database views—kanban, timeline, schedule, list—and includes a third-party plugin system for custom data types and custom “wheels” from the community.