The Tech Stack Behind Notion: Building a Block-Based Editor.

What if you could build a collaboration tool that serves 100 million users while keeping editing seamless? That’s exactly what Notion achieved; powering over 50% of Fortune 500 companies and managing 200 billion blocks with sub-second latency. With enterprise software spending hitting $1.25 trillion in 2025 and the custom software market projected to reach $334 billion by 2034, business leaders need tools that scale without compromise. However, how does a block-based editor handle massive scale while maintaining performance? In this deep dive, we unpack Notion’s complete tech stack; from React-based frontend architecture and custom contenteditable implementations to sharded PostgreSQL databases and the engineering decisions that make this collaboration possible. Let’s dive in:

Key Takeaways

• The block-based model allows unmatched content flexibility and reusability for enterprise teams.
• AWS provides core cloud infrastructure using EC2, S3, and RDS for hosting.
• Block transformations preserve content by changing only the type attribute while keeping properties.
• For enterprise teams, it means content can be reused, restructured, and repurposed across projects.
• Building a custom block editor MVP costs $50,000-$200,000.

What Makes Notion’s Block-Based Editor Unique?

Notion’s core innovation is simple yet revolutionary: “everything is a block”. Unlike traditional word processors that treat a page as a single unit, Notion breaks content into individual building blocks: text, images, headings, to-do lists, databases, and more. Each block is a self-contained unit with its own ID, type, properties, and content, inspired by the Lego system.

This block-based model gives enterprises unmatched content flexibility. Blocks can be dragged, rearranged, copied, or transformed into any other block type instantly without losing data. Indentation changes the actual structure by nesting blocks within parent blocks, organizing information hierarchically.

For enterprise teams, it means content can be reused, restructured, and repurposed across projects. A single block can live in multiple pages, update in real-time everywhere, and adapt to different workflows.

Overview of Notion’s Full Tech Stack

Notion powers over 100 million users and serves 50% of Fortune 500 companies with a scalable tech stack built for real-time collaboration. The company crossed $500 million in annual revenue by late 2025 and employs around 800-1,000 people, with 389 dedicated to product and engineering.

Frontend Technologies

Instead of complex web microservices, Notion relies on highly optimized pipelines:

• React.js & TypeScript: The foundation of the web client, wrapped statically for strongly typed UI rendering.
• Custom Reactive State Store: Replaces generic global state managers (like Redux) with optimized, block-level subscriber nodes to prevent cascading page re-renders.
• esbuild & Vite: Modern compilation tooling used to optimize, bundle, and code-split heavy JavaScript modules for immediate load times.
• Electron.js: Compiles the primary desktop experience for Windows and macOS, sharing core web client business logic.
• React Native: Powers native iOS and Android apps using a cross-platform.

Backend Technologies

Notion’s backend handles massive-scale real-time operations with better server-side architecture:

• Node.js Monolith: The central server-side application layer, running highly optimized, concurrent routines.
• WebSocket Infrastructure: The true vehicle for real-time collaborative multi-user updates, replacing generic polling and P2P protocols with persistent, secure socket lines.
• Operational Transformation Layer: Processes micro-transactions and operational deltas to guarantee that multi-user document changes merge without collisions.

Database & Caching Layer

Notion uses a data layer for reliability and fast access:

• Sharded PostgreSQL: The primary source of truth, scale-optimized by mapping 480 logical shards across a horizontally scaled architecture using workspace IDs as routing paths.
• Redis Enterprise Caching: An intensive in-memory data cache deployed in front of the database layer to serve common operations with sub-millisecond retrieval speeds.
• PgBouncer: A lightweight PostgreSQL connection pooler sitting between the application layer and the sharded database fleet; managing connection queues, minimizing resource consumption, and preventing the database from choking under high concurrent load.

Infrastructure & Cloud Architecture

Notion relies on cloud infrastructure for global scalability, for example:

• AWS (Amazon Web Services): Fully automated deployment infrastructure leveraging Amazon EC2 instances, S3 asset arrays, and fully monitored relational storage setups.
• Docker & Kubernetes: Container systems that abstract and auto-scale operational instances based on active regional user traffic.
• GitHub & Buildkite: The core DevOps engine, running intensive continuous integration, performance profiling, and continuous production deployments via highly distributed testing clusters.

Version Control & Collaboration

• Git & GitHub: Notion manages its massive application codebase inside a highly optimized GitHub Monorepo, allowing frontend, backend, and infrastructure teams to deploy atomic updates without breaking cross-boundary dependencies.
• Buildkite: Deployed as the primary distributed CI/CD pipeline engine, running isolated, self-hosted testing queues to validate code health swiftly before shipping to production.

This stack allows Notion to deliver real-time collaboration, sub-second latency, and 99.9% uptime; these are crucial benchmarks for such popular productivity tools.

How Notion’s Block Data Model Works?

Notion’s data model is built on an atomic, graph-like architecture where every piece of content is a block; such a design allows users to customize how information is moved, and shared at a granular level.

Block Attributes: What Determines Rendering and Organization?

Notion blocks have specific attributes that determine how information is rendered and organized:

Changing a block’s type does not change its properties or content;—only the type attribute changes, so information is rendered differently or ignored if the property is not used by that block type.

Nesting Architecture: Parent-Child Relationships

Notion organizes blocks hierarchically through parent-child relationships:

How Nesting Works

• Every block is independent by default, but some blocks are connected through nesting
• When you indent a block (using Tab), it becomes a child block; the unindented block becomes the parent
• Child blocks are stored in the parent’s children array
• You can only nest a block that has a different block above it (a parent must exist)

Nesting Rules

• Most basic block types can be nested under a block of the same type
• When you move or transform a parent block, all its child blocks are also moved or transformed
• Headings cannot be nested (Toggle Headings are an exception), nor can other blocks be nested under them
• Dividers, simple tables, database views, and some advanced blocks cannot be nested (except under toggle lists/headings)

Block Categories: Types in 6 Core Groups

Notion block types organized into six basic categories:

1. Text blocks: Pages, normal text, headings, bullet points, toggles, to-do lists, callouts, quotes
2. Inline blocks: Mentions, date objects (live within another block)
3. Media blocks: Images, video, audio uploads
4. Embed blocks: Content pulled from external websites (maps, YouTube videos, designs)
5. Database blocks: Rows and tables
6. Layout blocks: Columns, toggles, dividers

This graph-like, atomic data model brings flexibility, for instance you can change the block types, move freely and create customized tools.

Learn More,

Notion AI Agents: Complete Guide with Pricing, 5 Enterprise Use Cases & ROI Analysis (2026)

Frontend Architecture: Building the Editor in React

React-Based Editor Implementation

Notion’s frontend is built on React, but it takes a custom approach rather than relying on standard editor libraries. Each text block functions as an independent React component with its own contenteditable div, allowing fine-grained control over rendering and user interactions.

Custom Render Queue System

Instead of using React’s default rendering pipeline, Notion implements a custom render queue. Components call forceUpdate(), and Notion batches these updates to avoid excessive re-renders. Sub-second latency even with millions of blocks.

Transaction-based Editing Model

Every edit creates a transaction containing operations that modify block data. The view then re-renders data using React, maintaining consistency across the application. This approach allows reliable undo/redo functionality through inverted operations stored in a stack.

Editor Libraries: Why Notion Chooses Custom Over Tiptap/Slate?

Notion does not use off-the-shelf editor libraries like Tiptap, ProseMirror, or Slate. Instead, Notion maintains a custom contenteditable codebase built from scratch. It gives Notion full control over the block-based editing experience.

Why Custom Implementation Matters

Off-the-shelf libraries like Tiptap and Slate are excellent starting points for building block editors, but they lack the granular control needed for enterprise level collaboration. Notion’s custom implementation allows:

• Independent editable regions for each block
• Custom selection logic across blocks
• Fine-tuned performance optimization
• Full control over real-time collaboration features

Block Component Architecture

Each block handles its own editing independently. Layout uses CSS Flexbox for simple, responsive arrangements. Non-text blocks (images, embeds, databases) are regular DOM elements without contenteditable, reducing cursor logic complexity.

Key Custom Components

• Slash Command Menu: Custom-implemented / menu to insert block types
• Drag-and-Drop System: Custom-built for block reordering
• Cross-Block Selection: Triggers block-level highlighting instead of text selection
• Synced Blocks: Maintain consistency across multiple pages with visual indicators

Backend Systems: Scaling Block Operations

Notion’s backend handles hundreds of billions of blocks across 100M+ users using a Node.js monolith; a deliberate architectural choice that prioritizes data locality, operational simplicity, and low-latency access to Notion’s complex block graph over the overhead of decomposed services.

Client applications interface with Notion’s database via a dedicated API server, operating on a cluster of Node.js web servers. The connection to the database is managed through PgBouncer connection pooling, enhancing performance and scalability.

API Layer: REST Endpoints

Every resource in Notion’s API has an object meta property that tells you what kind of object is being dealt with. With the REST API, you can read, create, and update nearly everything in a workspace — pages, databases, users, comments, and more.

REST API Design

• Each block has a unique UUID accessible via /blocks/{block_id} endpoints
• CRUD operations (Create, Read, Update, Delete) map to standard HTTP methods
• Batch endpoints allow bulk block operations, reducing API call overhead
• Response payloads are minimized by returning only changed block properties
• API response times target sub-100ms latency for enterprise users

Monolith Architecture: How It Actually Works

Rather than decomposing into independently deployed services, Notion’s backend runs as a unified Node.js application. Notion kept the monolithic backend to maintain operational velocity and data locality, essential for their complex “block” graph — and focused entirely on sharding the persistence layer. It means block creation, page hierarchy management, search indexing, and real-time sync coordination all operate within the same application process, communicating in-memory rather than over a network.

This is a key distinction: Notion scales by sharding its database, not by splitting its application. The monolith handles routing requests to the correct database shard via workspace ID, while PgBouncer manages the connection pool to the sharded PostgreSQL fleet.

Real-Time Collaboration Layer

Notion’s platform leverages WebSocket-based real-time synchronization with conflict resolution algorithms to enable seamless collaborative editing across millions of concurrent users. WebSockets replace polling with persistent socket connections, and the conflict resolution layer ensures that concurrent edits from multiple users merge deterministically — without data loss or manual conflict prompts.

Concurrency Handling: Transactions and Locking

Transaction-Based Model

• Every edit creates a transaction containing operations that modify block data
• Transactions are atomic: either all operations succeed or none apply
• Operations are inverted for undo/redo functionality

Concurrency Strategies

• Optimistic Concurrency Control (OCC): allows multiple users to work simultaneously; conflicts are checked at commit time rather than blocking upfront
• Pessimistic locking: applied when multiple users edit the exact same block; first writer wins, others receive merge prompts
• Version vectors: each block tracks version history to detect and resolve conflicts

Database Scaling: Sharding and Replication

In 2021, the Postgres database was sharded to 32 physical instances with each instance comprising 15 logical shards. In 2023, they increased to 96 physical instances with 5 logical shards per instance, maintaining a total of 480 logical shards throughout. 

• Horizontal sharding: blocks distributed across databases by workspace ID
• Read replicas: handle the majority of read traffic, reducing primary database load
• Redis caching: frequently accessed blocks cached in-memory for sub-millisecond retrieval

This architecture — a monolith application layer routing to a massively sharded database — allows Notion to maintain sub-second latency while serving enterprise-scale workloads without the operational complexity of a full microservices stack.

Concurrency Handling: Transactions and Locking

Real-time collaboration needs advanced concurrency control to prevent data conflicts:

Transaction-Based Model

• Every edit creates a transaction containing operations that modify block data
• Transactions are atomic: either all operations succeed or none apply
• Operations are inverted for undo/redo functionality

Concurrency Strategies

• Optimistic locking: Multiple users can edit different blocks simultaneously without blocking
• Pessimistic locking: Applied when multiple users edit the same block; first writer wins, others receive merge prompts
• Notion uses Optimistic Concurrency Control (OCC) coupled with a custom transaction execution layer.
• Version vectors: Each block tracks version history to detect and resolve conflicts

Database Scaling: Sharding and Replication

Notion’s PostgreSQL database was sharded from 1 to 32 physical database instances housing 480 logical shards:

• Horizontal sharding: Blocks distributed across databases by workspace ID
• Read replicas: Handle 90% of read traffic that reduces primary database load
• Redis caching: Frequently accessed blocks cached in-memory for sub-millisecond retrieval

This architecture allows Notion to maintain sub-second latency while serving enterprise-scale workloads.

Challenges in Building a Block Editor for Enterprise

Building a block-based editor like Notion presents different engineering hurdles. Notion serves over 100 million users and manages 200 billion blocks. Here are the key challenges and how Notion solved them:

Database Scaling and Sharding

Notion’s data growth was exponential; doubling every 6-12 months as hundreds of billions of blocks accumulated.

The Challenge

• Started with a single PostgreSQL database that could not handle the scale
• Hundreds of terabytes of data overwhelmed the system
• Engineers faced constant alerts at night due to database performance issues

Notion’s Solution

• Sharded the database: 32 physical database instances housing 480 logical shards
• Carefully planned data migration with only 5 minutes of downtime
• Built custom data pipeline using Kafka, Apache Hudi, and S3 for handling update-heavy workloads

Real-Time Conflict Resolution

Multiple users editing the same block creates conflicts that must be resolved without data loss.

The Challenge

• Cross-block selection and editing across distributed systems is complex
• Need sub-second latency for a smooth user experience

Notion’s Solution

Notion’s technology infrastructure uses WebSocket-based real-time synchronization with conflict resolution algorithms to enable seamless collaborative editing across millions of concurrent users. 

Versioning and Migration Complexity

Block transformations and data migrations require preserving relationships and preventing data loss.

The Challenge

• Block types can be transformed (paragraph → heading → bullet), but properties must be preserved
• Export formats are not user-friendly; exports consist of raw data in hashed folders
• Moving large datasets between workspaces is difficult due to poor data portability

Notion’s Solution

• Transform operations preserve content: When changing block type, only the type attribute changes; properties not used by the new type are ignored
• Inverted operations for undo/redo: Uses a stack with inverted operations to maintain version history
• Synced blocks maintain connections across pages, with clear options to sync, unsync, or unsync all

Performance at Scale

Maintaining sub-second latency while serving 100M+ users requires careful optimization.

The Challenge

• React’s default rendering would re-render entire component trees on every edit.
• Each block is an independent contenteditable div; coordinating updates across thousands of blocks creates synchronization bottlenecks
• Managing cursor position, selection, and text formatting across multiple blocks needs complex state management
• Every block operation queries the database; without caching, PostgreSQL becomes a bottleneck under high concurrency

Notion’s Solution

• Custom render queue batching to avoid excessive re-renders
• Each block handles its own editing independently
• Non-text blocks (images, embeds) are regular DOM elements without contenteditable, reducing cursor logic complexity
• Redis caching layer reduces database load for common operations

These engineering solutions on Notion deliver real-time collaboration and maintain flexibility, data integrity.

7 Lessons for Enterprise Owners Building Similar Tools

Enterprise owners building block-based collaboration tools face complex decisions. Here are seven actionable lessons from Notion’s journey serving 100M+ users and 50% of Fortune 500 companies.

1. Build Custom When Off-the-Shelf Won’t Fit

Notion does not use Tiptap, Slate, or ProseMirror; it built a custom contenteditable codebase from scratch. For enterprise tools requiring unique features like block-based editing, buying rarely works. Custom development costs more upfront but provides full control over performance, features, and scalability.

2. Choose Technologies That Scale with Data Growth

Notion started with a single PostgreSQL database that could not handle 200 billion blocks doubling every 6-12 months. They sharded to 32 physical database instances housing 480 logical shards with only 5 minutes of downtime. Lesson? Choose databases and infrastructure that support horizontal scaling from day one. Notion’s stack—PostgreSQL, Redis, AWS, Kubernetes; handles heavy workloads.

3. Invest in Real-Time Collaboration Infrastructure Early

Building real-time sync is hard. Notion built a centralized WebSocket signaling and state broadcast pipeline to meet performance standards. Real-time collaboration needs sub-second latency and conflict resolution that off-the-shelf solutions struggle to deliver.

4. Build a Specialized Engineering Team, Not Just a Large One

Notion employs around 1,000 people, with 389 dedicated to product and engineering. That is nearly 40% of the workforce focused on engineering. For custom tools, you need specialized engineers (database architects, real-time systems experts, frontend specialists), not just generic developers. Quality trumps quantity.

5. Calculate Total Cost of Ownership

Notion crossed $500 million in annual revenue by late 2025 and spends ~10% of revenue on AI providers. Building custom software involves ongoing costs: infrastructure, maintenance, security, compliance, and updates. Pre-built solutions offer transparent, predictable subscription costs but sacrifice control. For enterprise tools, build only when ROI justifies multi-year development.

6. Prioritize Compliance and Security from Day One

Enterprise buyers require SOC 2, GDPR, SSO, and admin controls. Notion’s features serve Fortune 500 brands because they meet compliance standards. Do not bolt security on later; build it into your architecture. Data encryption, access controls, and audit logs are non-negotiable for enterprise tools.

7. Plan for Data Portability and Migration Complexity

Notion’s exports are raw data in hashed folders, not user-friendly. Moving large datasets between workspaces is difficult! So you need to build clean API endpoints, export formats, and migration tools from the start. Enterprises need data portability for compliance and vendor lock-in concerns. Poor data portability becomes a major buying barrier for enterprise customers.

Conclusion

Building a block editor like Notion requires $50M+ in development costs, specialized talent, and 3-5 years to reach maturity. Buying makes sense when speed-to-market matters. Building makes sense when unique features, control, and long-term ROI justify the investment. For enterprise collaboration tools, the decision hinges on whether your differentiator is the technology itself or the business problem you are solving. Ready to build a custom enterprise platform? At TechAhead, we specialize in building custom solutions and seamlessly integrating them with your existing systems whether legacy infrastructure or modern platforms. Contact TechAhead today for a free technical consultation and let’s build a custom solution that drives real ROI for your business.