---
title: "pg_crdt - an experimental CRDT extension for Postgres"
description: "Supabase announces pg_crdt, an experimental Postgres extension that adds CRDT support as a data type for collaborative and offline-oriented applications. It frames CRDTs as structures whose updates can be merged in any order to reach the same final state, avoiding the last-write-wins behavior of ordinary arrays. A content column can use crdt.ydoc, backed by Yjs, while the extension also supports Automerge through Rust libraries wrapped with pgx. The post contrasts storing CRDTs directly in Postgres with making Realtime an authoritative server, favoring the database-centered approach for simpler architecture and broader tooling, while noting that the decision is unsettled and pg_crdt is not released on the Supabase platform. Known limitations include full-document WAL broadcasts, increased WAL and dead tuples for frequently updated documents, and serialization overhead for large CRDT values."
---

# pg\_crdt - an experimental CRDT extension for Postgres

[Supabase](https://yomu.fyi/company/supabase) · paul\_copplestone · Dec 10, 2022

**Type:** Announcement

## Summary

Supabase announces pg\_crdt, an experimental Postgres extension that adds CRDT support as a data type for collaborative and offline-oriented applications. It frames CRDTs as structures whose updates can be merged in any order to reach the same final state, avoiding the last-write-wins behavior of ordinary arrays. A content column can use crdt.ydoc, backed by Yjs, while the extension also supports Automerge through Rust libraries wrapped with pgx. The post contrasts storing CRDTs directly in Postgres with making Realtime an authoritative server, favoring the database-centered approach for simpler architecture and broader tooling, while noting that the decision is unsettled and pg\_crdt is not released on the Supabase platform. Known limitations include full-document WAL broadcasts, increased WAL and dead tuples for frequently updated documents, and serialization overhead for large CRDT values.

## Context

Collaborative applications need a way to merge concurrent changes from multiple users, including changes made offline. The post questions whether Postgres can support row-level CRDT merging while also handling merge strategies for every data type in its evolving ecosystem, and suggests that applications may need different levels of offline support.

## Approach / What changed

pg\_crdt adds CRDTs to Postgres as a data type, including a crdt.ydoc column backed by Yjs. It also supports Automerge through Rust libraries wrapped with the pgx framework. The post compares this database-centered design with using Realtime as an authoritative server, and argues that storing CRDTs in Postgres could simplify the architecture, support tools such as Debezium, and allow direct database updates.

## Takeaways

- CRDT updates are commutative and idempotent in pg\_crdt, so they can be applied in different orders or multiple times while producing the same result.
- The extension supports Yjs and Automerge, whose Rust implementations can run in both browser and Postgres environments through the extension.
- Postgres integration currently has major costs: WAL broadcasts include the complete document, frequent updates create substantial WAL and dead tuples, and large CRDT values add serialization overhead.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Open Source](https://yomu.fyi/topic/open-source), [Performance](https://yomu.fyi/topic/performance), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Supabase](https://supabase.com/blog/postgres-crdt)
- Source URL: https://supabase.com/blog/postgres-crdt
- Ingested by Yomu: 2026-08-29T01:15:17.246Z

[Read original post](https://supabase.com/blog/postgres-crdt)