目錄
This week, a very specific experience report appeared on r/Notion. One user who had been using Notion for three years said that documents and the Wiki were still parts of the workspace the team genuinely liked. The pressure started elsewhere: the operational systems that had gradually been added on top of Notion, including a CRM built with linked databases, approval flows, and several trackers with real business logic. According to this user’s experience, once the team grew past 50 people, larger databases started to feel slower, permissions and automation became increasingly difficult to manage, and the team eventually began considering moving the “operational half” elsewhere while keeping Notion for the documents and Wiki it still handled well.
However, 50 people should not be treated as a product limit for Notion. Notion has no official rule saying that it becomes unsuitable once a team exceeds 50 members, and it currently still offers Business and Enterprise plans, database page-level access, Sprints, Charts, and support for large databases. What usually determines when a workspace begins to feel slow or difficult to maintain is the data architecture itself: the number of pages, the number of properties, complex Formulas and Rollups, Filters and Sorts, and how many databases are loaded at once on a high-traffic page. In other words, team size is more likely to expose problems that were already hidden in the architecture. Notion does not suddenly stop working when the 51st person logs in.
For teams considering moving CRM, approvals, project management, or more internal processes into Notion, this is a harder question than simply comparing plan prices. Pricing can be changed next month by switching plans. A workspace architecture that has accumulated years of data, Relations, Automations, and user habits is much harder to move. The following sections summarize several common issues reflected in this week’s r/Notion discussions and the boundaries worth thinking through before building a workspace. (This article reflects information available as of August 2026. Notion features and limits may continue to change.)
Is Notion No Longer Suitable Once a Team Exceeds 50 People? The Real Issue Is Not Headcount
A Three-Year User’s Breaking Point: Keep Docs and Wiki, Move the Operational Systems
The title of the r/Notion post already captured the issue clearly: the user might need to find an alternative for “the half of Notion that isn’t Docs.” The poster had used Notion for three years and opened by saying they would still defend its documentation and Wiki features. The problems appeared after the team started placing more workflows into the workspace, including a CRM built with Linked Databases, an Approval Flow, and roughly half a dozen trackers containing actual business logic. Once the team reached more than 50 people, the poster began encountering slower large databases, increasingly complicated permission management, and situations where third-party Automation was needed to supplement reactive workflows.
This is the real-world experience of one team, not an official Notion performance benchmark. It is therefore more useful as a case study for “when should we re-evaluate the architecture?” than as a rule saying “leave Notion once you reach 50 people.” Notion’s own performance documentation does not use team headcount as the main criterion. Instead, it lists the factors that can actually slow databases down: too many pages, too many visible properties, overly complex Formula and Rollup references, Sorts and Filters based on complex properties, and high-traffic dashboards that load many Inline Databases at the same time.
A single Notion database can currently contain up to 250,000 rows, but being below a hard limit does not guarantee that the experience will always feel fast. Notion specifically recommends that large workspaces avoid placing too many Inline Databases on high-traffic pages and avoid deep Formula and Rollup dependency chains. These issues may be barely noticeable in a five-person team. Once data volume, user count, and workflows all increase together, however, opening a dashboard, recalculating formulas, or adjusting a view may start to feel noticeably slower.
“Permissions Are Basically All or Nothing” Now Needs to Be Corrected
The original Reddit post described Notion Permissions as “basically all or nothing,” but repeating that statement directly today would no longer accurately reflect the product. Business and Enterprise plans now support database page-level access, allowing access to specific Database Pages to be determined through Person Properties or Created by Properties. For example, a customer support ticket system can allow users to see only the tickets they created, while contractors can be limited to tasks assigned specifically to them.
Notion also provides Can edit content, which allows members to modify database content without changing Properties, Views, Filters, or Sorts. Business and Enterprise additionally offer Can create, which allows users to add new records without automatically seeing existing records unless separate permissions are granted. The more accurate question today is therefore not “Does Notion lack granular permissions?” but rather “Can Notion’s current permission model support the specific rules required by this CRM, approval flow, or operational system?”
For example, if a company needs access permissions to be calculated dynamically across departments, customers, deal stages, and roles, or requires very granular field-level permissions, audit rules, and complex approval conditions, a specialized CRM or operational database may still be a better fit. That is a different claim from saying Notion has no row-level permission controls at all.
Why Do Notion Databases Get Slower Over Time? Notion Has Already Listed Several Common Causes
Large Databases Are Not the Only Problem—References and Display Structure Matter More
Notion’s current performance guidance is fairly specific. As the number of database Pages increases, load times may increase. More Visible Properties also mean more content needs to be processed. If a View uses Formula, Rollup, text, or other complex properties for Filters or Sorts, the amount of computation rises further. One of the easiest problems to miss is the Reference Chain: a Formula depends on another Formula, which in turn depends on a Rollup. Architectures like this become significantly more expensive to calculate as the amount of data grows.
This is also what often happens to “Everything in Notion” workspaces over time. A workspace may begin with only Projects and Tasks. Later, it adds Clients, Meetings, Invoices, Approvals, Objectives, and Sprints, with all of them connected through Relations and Rollups. Every individual feature is possible on its own, but the system eventually becomes a chain of interdependent databases. Changing one property may affect several dashboards and formulas elsewhere.
Notion’s recommendations for large Workspaces are also practical. High-traffic pages should not load many Inline Databases at once. A team can instead use a Linked Database with different Views pointing to the appropriate data, so the interface only loads the View currently being used. Unnecessary Properties can be hidden, and simple fields such as Status, Date, and Select can be used to reduce the number of Pages being processed before applying more complex Filters.
50 People Is More Like the Point When Symptoms Appear, Not the Cause
If a five-person team creates only a few records per day, even a complicated architecture may not cause obvious problems in the short term. Give the same structure to 50 people who add Tasks, CRM Records, Comments, Approvals, and Project Updates every day, and the accumulation rate changes completely. This is why the Reddit poster remembers the 50-person mark as a breaking point, while Notion’s own performance documentation focuses on data volume and database logic rather than headcount.
A more useful way to assess a workspace than asking “How many people are in the company?” is to ask how many core databases exist, how many Views are loaded on a dashboard at once, how many Formula and Rollup dependencies exist, and how many Records are added every day. When these numbers start increasing, it becomes more important to decide which workflows belong in Notion and which data should be handled by a specialized system.
Are Productivity Templates Still Being Used a Year Later? Maintenance Cost Is Also a Scaling Problem
A Workspace Is Not Finished Once It Is Built—the Real Question Is Whether Anyone Still Wants to Maintain It Six Months Later
Another r/Notion discussion from the same week suggested creating a “Productivity template one year later” thread, questioning how many highly designed Second Brain and Productivity Templates with heavy maintenance requirements were still actually being used after one year. In another similar discussion, one user said they had downloaded dozens of Second Brain systems, Habit Trackers, Personal CRMs, Content Calendars, and other templates over several years, but currently used none of them. Friends who abandoned similar systems usually did not do so because the templates were bad. The systems gradually became another job that needed to be maintained.
This is essentially the same problem as the 50-person company case, only at a different scale. A personal template may require someone to clean up an Inbox every week, maintain a dozen Properties, and file every note into the correct database. An enterprise Workspace may require every team member to update CRM Stage, Project Status, Approvals, Sprints, and associated Relations. Once the maintenance process requires more effort than the system actually saves, users start skipping updates. When the data is no longer accurate, the carefully designed Dashboard loses its value as well.
So when evaluating a Notion architecture, “Can this be built?” is only the first question. The next question should be: will people still be willing to follow these rules six months from now? If a system depends on everyone remembering to manually maintain many fields, the eventual problem may not be Notion’s functionality. It may be that the process demands too much from the people using it.
Is Notion Good Enough for Project Management? Growing Small Teams Eventually Start Needing More Reporting
Before Hiring Its First Full-Time Engineer, a Small Agency Started Worrying About Burndown and Cost Metrics
Another r/Notion user shared that a small agency was about to hire its first full-time Developer. Task Templates, SOPs, Customer Conversations, and company Context were already almost entirely stored in Notion. The concern began when the team started needing more structured PM and PMO information, such as Automated Burndown, Budget vs Actuals, and other Productivity Metrics.
This should not be simplified into “Notion cannot do project management.” Notion now offers Task Databases, Sprints, Dependencies, Timeline, and Charts. Sprint Databases can even display the completion percentage for each Sprint and automatically move unfinished Tasks into the next Sprint. Notion’s own documentation also presents Project Management, Engineering Sprints, and progress tracking as official database use cases.
The difference is closer to “Can the team build it themselves?” versus “Does the system provide this structure out of the box?” If the requirement is simply to see Task completion rates, a Project Timeline, or a basic Chart, Notion can already handle a significant amount. If the team needs mature Burndown, Velocity, Capacity Planning, Budget Variance, and reporting tightly integrated with code Issues and PRs, specialized PM tools usually reduce the amount of custom modeling and maintenance required.
This is another common change that appears as teams grow. In a small team, everyone knows what everyone else is working on, and a quick question in a meeting may be enough. Add another function and several concurrent projects, and managers begin needing metrics that can be calculated repeatedly and compared week after week. A flexible Database that once felt simple may then require more formulas and reports, increasing maintenance costs again.
Why Do People Still Complain About Notion Calendar? Database Calendar and Notion Calendar Are Two Different Things
Notion Databases Can Have a Calendar View, but Full Notion Calendar Still Uses a Separate Interface
Another r/Notion post this week complained that, even years after Notion Calendar launched, the full Notion Calendar still cannot be directly placed inside an ordinary Notion Page. This description broadly matches the functionality currently documented by Notion. A Notion Database can be connected to Notion Calendar so that Pages with Date Properties appear in the Calendar App, and Database Items can be created or edited directly from Calendar. In the other direction, however, there is still no official feature that allows the full Notion Calendar App to be embedded as a native Block inside a standard Notion Page.
The source of confusion is that a Notion Page can already contain a Calendar View. That View displays Records with dates from a specific Database. It is different from Notion Calendar, the separate product that can connect Google or Apple Calendar together with multiple Notion Databases. Notion currently allows up to 20 Notion Databases to be added to Notion Calendar, and Database Pages can be managed directly from Calendar, but the two interfaces have still not been merged into a single Page Block.
The more accurate description of this pain point is therefore “Notion Calendar and the Notion Page interface are still not fully integrated,” rather than “Notion does not have a calendar.” Those are very different statements.
Another Architecture: Use Notion as the Data and Knowledge Layer Without Keeping All Execution Logic Inside It
A Notion Plus Claude Case Study Centralized SOPs, CRM, and Meeting Notes into One Context Layer
There was also a completely opposite kind of post in the same week. One business owner said they had centralized SOPs, Meeting Notes, and CRM inside Notion and then allowed Claude to directly read and write that Context. Their workflows included drafting follow-up emails after Sales Calls, extracting KPIs from meeting Transcripts and updating Databases, and generating content based on previous Newsletters and internal notes. The poster claimed the setup saved more than ten hours per week. However, this was an individual result and was also connected to the author’s own operational content promotion, so it should not be treated as an outcome every team can expect.
What makes this case more interesting is that Notion itself does not have to carry all of the logic. The workspace stores SOPs, CRM data, meeting notes, and other company Context, while Claude reads the information, performs reasoning, generates outputs, and writes necessary results back into Notion. This is closer to using Notion as a knowledge and Context Layer rather than forcing every workflow into a chain of Notion Formulas, Rollups, and Automations.
This approach introduces a different set of problems, including external AI permissions, data security, API or subscription costs, and incorrect writes. But it also suggests another architectural direction: Notion being a good place to store information does not mean every piece of execution logic must also live inside Notion.
When a Notion Workspace Starts Getting Complicated, Check These Three Boundaries First
Keep Documents and Knowledge in Notion; Decide Process Systems Based on Their Requirements
Docs, Wiki, Meeting Notes, SOPs, and long-term knowledge usually do not depend heavily on real-time calculations, complex permissions, or transaction logic. That is also why the original three-year user still wanted to keep Notion as the Wiki even while considering moving CRM and operational workflows elsewhere.
CRM, Approval, Finance, and Engineering Project Management workflows deserve a different set of questions. Do they require many conditional permission rules? Do they need fixed management metrics generated automatically? Do they contain large volumes of transactional records? Do core actions frequently depend on third-party Automation? If the answer increasingly becomes “yes,” it is worth comparing specialized tools instead of continuing to add more fields to the same Database.
Before Adding a Feature, Include Its Maintenance Cost One Year From Now
A beautifully designed Workspace makes it easy to underestimate long-term maintenance. Every added Relation, Status, Dashboard, or Automation does not just add a feature. It also creates something that someone will need to understand, fix, and update later. The template discussion’s idea that “eventually the system itself becomes something you have to maintain” applies equally well to company workspaces.
When building a new workflow, teams can ask directly: if the person who built this system leaves in six months, will anyone else still understand it? If the amount of data becomes ten times larger, will the Formulas and Dashboards still work well? If an Integration fails, will the core process fail with it? These questions are more useful for judging whether a system will last than asking whether one more attractive View can be added.
You Do Not Need to Wait Until the Entire System Breaks Before Deciding What Data Should Move
Moving everything out of Notion is usually unnecessary. The original Reddit poster was also considering a split architecture: keep Docs and Wiki in Notion while moving the Operational Half to tools better suited to complex data and permissions. Commenters suggested similar approaches, arguing that when a CRM outgrows Notion, the team can migrate only the CRM rather than rebuilding the entire company knowledge base because one workflow reached its limits.
A more practical approach is to define the Source of Truth for each system while the architecture still works. Does the customer master record live in Notion or the CRM? Are engineering Issues officially tracked in GitHub, Linear, or Notion? Where do documents live? Which data is only synchronized for display? If those boundaries are defined early, moving one layer later does not require dismantling everything at once.
Notion does not have a clear rule saying that it becomes unsuitable after 50 people. The 50-plus-person experience shared by the three-year user this week is better understood as the point where architectural pressure became visible: the CRM grew larger, approval flows increased, trackers accumulated more logic, and a tool that had originally worked well for documents gradually began carrying the responsibilities of an operational system. Notion’s own performance documentation also indicates that the factors that slow large Workspaces down are data volume, Properties, Formula and Rollup references, Filters, and the number of Databases loaded at once—not simply the number of Members.
So the question does not need to become “Can Notion be a Company OS?” A more practical approach is to look at what each layer of the workspace is responsible for. If documents and company knowledge work well, keep them there. If CRM, engineering management, or approval workflows already require numerous workarounds, evaluate those systems separately. The hardest thing to migrate is not a Database. It is reaching the point where, after several years, nobody knows which version of the data is actually the official one.
FAQ
No. More than 50 people was simply the point at which one team in the Reddit post began feeling that its workspace was under strain. Notion has not published a 50-person usage limit. The performance factors listed by Notion mainly involve database Pages, Properties, Formula and Rollup complexity, Filters, Sorts, and the number of databases loaded at the same time. The actual threshold therefore depends on workspace architecture and data volume.
In this particular case, the main problems appeared in CRM, Approval Flow, and several logic-heavy Trackers. Another small agency began reconsidering Notion once it needed Automated Burndown, Budget vs Actuals, and PMO metrics. These are individual user experiences and should not be treated as universal, but they share one characteristic: the workflows increasingly required more fixed data models, permissions, Automation, and management reporting.
No. Business and Enterprise currently support database page-level access, allowing View, Comment, or Edit permissions for specific Database Pages to be assigned through Person or Created by Properties. Notion also provides permission levels such as Can edit content and Can create. Whether these controls are sufficient to replace the permission model of a specialized CRM still depends on the complexity of the actual workflow.
Current official documentation still does not provide a native way to embed the full Notion Calendar App inside a regular Notion Page. A Notion Database can have its own Calendar View and can also be connected to the separate Notion Calendar App, but the two interfaces remain distinct features.
Start with three questions: does daily work require a large amount of manual maintenance across Properties, Relations, and Dashboards? Do core workflows depend heavily on third-party Automation to function? Are databases becoming slower because of complex Formulas, Rollups, Filters, or large numbers of Views? If maintaining the system itself increasingly consumes more time, it may be worth moving specific workflows elsewhere instead of continuing to add more features to the same architecture.