Building and scaling Notion's data lake (www.notion.com)

Notion built an in-house data lake to handle a tenfold surge in content—growing from ~20 billion to over 200 billion “block” rows in Postgres over three years—and to relieve operational and cost pain from an update-heavy workload (about 90% of block upserts). Their legacy pipeline (480 Fivetran connectors feeding Snowflake) became hard to operate, slow and expensive for frequent updates, and insufficient for compute-heavy denormalization tasks (e.g., permission tree traversals required by AI and Search). Rather than replace Snowflake or Fivetran entirely, Notion designed a hybrid architecture focused on offline workloads that tolerate minutes-to-hours latency. Technically, the stack ingests Postgres changes via Debezium CDC into Kafka (one topic per table aggregating 480 shards), uses Apache Hudi to materialize change streams to S3, and runs large-scale transformations in Spark (PySpark/Scala) for denormalization, enrichment and permission computation. They chose S3 for scale/cost and Spark for rich UDFs and fine-grained resource control; Hudi was selected over Iceberg/Delta for better handling of update-heavy data and Debezium integration. The result: fresher, cheaper, and more operable offline pipelines (latency from minutes up to ~2 hours for the largest table), unlocking AI, Search, and analytics use cases that require large-scale denormalized views.