Why is Notion so slow? What Notion's own engineers say
Why Notion is slow, in its own engineers' words: blocks, one shared database, a late cache and your own databases, and what to do without leaving.
PS
Prashant Shaw
Founder, Sumibako
6 min read
Search for "why is Notion so slow" and you get advice from people with something to sell. The first page I was served held guides from five companies: Super (two of them), Bullet, Falconer, Fabric and Gridfiti. Between them they sell websites built on Notion, templates for Notion, and ways out of Notion. I build a notes app, which makes me the sixth salesman at the door. My pitch is the last section, labelled, and you can leave before it.
The better source is Notion. Its engineers have been explaining in public why it is slow since 2021. One of the six guides, Falconer's, links two of those posts, and credit to them. None of the six mentions the pair that explains the most: the ones about the cache, which include a list of what got worse. Everything below is linked and was checked on 12 October 2026.
📣 Notion said it first
In April 2021 a Notion engineer opened a post with: "Lately, the #1 piece of feedback we've heard from users has been unambiguous: Notion feels slow."
No competitor has put it better, and several have tried. Notion has since written up the causes one at a time.
"Pages on Windows open 27% faster, Mac desktop is up +11%."
Four causes come out of those links. Two are largely fixed. Two are the product.
🧱 Cause one: everything is a block
A paragraph is a block. So is an image, a list item, a row in a database, and the page itself. The sharding post adds the detail that matters: each block is "occupying a row in our database".
That is what lets any block become another kind of block, and why opening a page is not opening a file. The app starts at the page and walks down a tree, and the data model post is frank about the bad days: "in the worst case, this API might need many trips to the database as it recursively crawls down the tree to chase down blocks and their record dependencies."
Then there is the live part. "Every client has a long-lived WebSocket connection" to Notion's update service and subscribes to each record it draws, which is how a colleague's keystroke reaches your screen. A long page is a long list of things to fetch and to listen to: a lot of machinery for a shopping list, and about right for a document twelve people are editing.
🐘 Cause two: one database for everybody
Until 2021, every block from every customer lived in a single Postgres database. The sharding post describes the end: "Engineers on-call often woke up to database CPU spikes". They split it into "480 logical shards evenly distributed across 32 physical databases", during "five minutes of scheduled maintenance".
If your memory of slow Notion dates from 2020, this is a likely suspect, since dealt with. The post is called "Herding elephants", after the Postgres mascot and not, I assume, the customers.
💾 Cause three: the app kept forgetting
The fix for asking the server every time is a cache: a SQLite database on your device that remembers pages you have opened. The desktop apps got it in 2021. Browsers waited until 2024, and it was hard: an early build corrupted the cache for some people, who saw "a comment attributed to the wrong co-worker".
The 2024 post is the useful one, because it says what did not improve.
Moving between pages got 20 percent faster. The first page after you open Notion did not, because it "wasn't typically bottlenecked on data fetching". The app is busy starting up, which no cache helps.
Some phones got worse at first. "Certain devices, like mobile phones whose browsers were pointed at Notion, didn't benefit from the caching, and in fact even got worse." Older Android phones "read from the disk extremely slowly", so Notion now races the cache against the network.
The slower your connection, the more it helped: 28 percent in Australia, 31 in China, 33 in India.
🗄️ Cause four: your databases
This one is yours, and Notion's help centre says so politely. Three things slow a database: how many pages it holds, how many properties are visible, and sorts or filters on "title, text, formula, or rollup". Formulas stack: "a formula that depends on several other formulas that each depend on rollups may take longer to calculate." Dashboards cost more than they look: "The more simultaneously viewed databases, the more stress on your setup."
🔧 What to do, staying in Notion
The first two are my reading. The rest is Notion's advice.
Judge it on the second page, not the first. The cache helps moving around, not starting up, so leave Notion open.
If you live in a browser tab, try the desktop app. It has had the cache three years longer, and it can work offline, which the help centre says "isn't available on web browsers".
On a slow page, look for databases first. Give each its own page. To show several together, use one linked database with a view per source, because then "only that one database is listening for updates".
Hide properties you never read, which "may improve responsiveness and interactivity".
Filter on plain properties: "select, multi-select, status, number, and date". Keep sorts and filters off formulas and rollups.
Filter old pages out by Created time, which "may significantly improve performance for very large databases".
📝NOTE
Every percentage here is Notion's measurement of Notion, and the newest engineering post on loading speed I could find is from July 2024. I timed nothing myself. If a number has changed, write to hello@sumibako.com and I will fix it and move the date.
🪶 Where a smaller app does less, and what that costs
This is the part I build, so adjust your trust accordingly. Sumibako is a notes app in a browser tab. I have no stopwatch number to print, so here is the argument from design: it does less.
A page is stored whole, not as a row per paragraph, so opening one is no walk down a tree. The rest is what Notion has and mine does not.
Notion
Sumibako
Databases
Yes, up to 250,000 rows each
None
Editing together, live
Yes
None
Comments
Yes
None
AI in the app
Yes
None. An AI app you already use can file pages through a connector
Offline
Desktop and mobile apps, on every plan
Only inside a tab that is already open
Local cache
SQLite
IndexedDB
That last row: Notion's desktop apps left IndexedDB in 2021 because it "wouldn't scale with Notion's growing user base". I look forward to having that problem.
If your slow page is a dashboard, stay and use the list above. Nothing I make replaces a database. If your slow pages are plain writing and you mostly work alone, a plainer app has less to do. Any plainer app: I went through ten in another post. Before you move anything, read what survives a Notion export, because databases do not travel well. Mine has an import guide for it.
Notion is slow the way a Swiss Army knife is heavy. The weight is the tools. The useful question is not why it is slow, but how many of the blades you ever open.
🙅
Notion alternatives without AI, and whether you can turn Notion's off
Whether Notion AI can be switched off, and on which plans. Then ten notes apps checked for AI on their own sites, from none at all to off until you say so.
