Case study · Stack

How Notion scaled Postgres and its data stack

Notion is a workspace where teams write docs, build wikis and manage projects, all made of blocks. Its product runs on React, TypeScript and Node.js over a sharded Postgres fleet on AWS, with a Kafka, Hudi and Spark data lake built to keep up with billions of blocks.
Copy this stacknotion.com Connected workspace for docs, wikis and projects · United States · founded 2013

Language

UI library

Hosting

  • AWSnotion.com

    Cloud for databases (RDS), storage (S3) and Kubernetes (EKS).

Database

  • PostgreSQLnotion.com

    Main production database, sharded by workspace into 480 logical shards on Amazon RDS.

Mobile framework

Data fetching

  • Kafkanotion.com

    Carries Postgres change events into the data lake, one topic per table.

    Why: Chosen for scalability and tight integration with their existing infrastructure.

  • Debeziumnotion.com

    Captures row changes from each Postgres host and publishes them to Kafka.

    Why: Picked for scalability, easy setup and fit with their infrastructure.

  • Apache Hudinotion.com

    Writes the change stream from Kafka into tables on S3.

    Why: It handled their update-heavy workload better than Iceberg or Delta Lake did in 2022.

  • Apache Sparknotion.com

    Main engine for transforming and denormalizing block data, in PySpark and Scala.

    Why: It offers functions beyond SQL, scales out, and is open source.

  • Snowflakenotion.com

    Analytics warehouse, kept for insert-heavy workloads.

  • SQLitenotion.com

    Client-side cache in the desktop apps and, via WebAssembly, in the browser.

    Why: Caching in SQLite had already made desktop loads about 50% faster, so they extended it to the web.

Backend framework

File storage

  • Amazon S3notion.com

    Central storage for the raw and processed data lake.

    Why: It fit their AWS stack and stores large volumes cheaply for many processing engines.

Search

  • Elasticsearchnotion.com

    Powers search, fed from the data lake.

How they built it

From one Postgres monolith to 480 shards

For about five years Notion ran on a single Postgres database. By 2021 the monolith was waking on-call engineers with CPU spikes, and stalled VACUUM raised the risk of transaction ID wraparound.

The team sharded at the application level instead of adopting Citus or Vitess, to keep control over how data was distributed. Data is partitioned by workspace ID into 480 logical shards, first spread over 32 physical databases and later over 96.

Sources:notion.com notion.com

Building an in-house data lake

Notion first copied Postgres into Snowflake with Fivetran. That worked for append-heavy data but not for Notion's update-heavy blocks, so in 2022 the team built its own lake.

Debezium captures Postgres changes into Kafka, Apache Hudi writes them to Amazon S3, and Spark does the heavy processing. Snowflake and Fivetran stayed for the cases where they still fit, and the cleaned data feeds search and AI features.

Sources:notion.com

SQLite on the client for faster loads

In 2021 Notion added a SQLite cache to its Mac and Windows apps, which made first page loads and navigation about 50% faster.

Later it brought the same idea to the browser with the WebAssembly build of SQLite, stored in OPFS and coordinated across tabs by a SharedWorker. Page navigation got about 20% faster in modern browsers.

Sources:notion.com

Native mobile apps with a shared Rust layer

Notion's current job posts describe native mobile apps: Android is built with Kotlin and Jetpack Compose, and both iOS and Android share a Rust layer.

On the web and server side, the posts list the same core stack: React, TypeScript, Node.js, Postgres and Elasticsearch, with Go appearing in database infrastructure work.

Sources:jobs.ashbyhq.com jobs.ashbyhq.com jobs.ashbyhq.com jobs.ashbyhq.com

Also detected on their website

Found on the homepage with the open Wappalyzer rules (HTML, scripts and headers). It shows what runs in the browser, not the whole backend.

  • Algolia
  • Cloudflare
  • Cloudflare Bot Management
  • Contentful
  • HSTS
  • Linkedin Ads
  • Linkedin Insight Tag
  • Naver Analytics
  • Next.js
  • Vercel
  • Webpack
  • hCaptcha