Notion Query Data Source Usage Limit: What Counts and How to Fix It

The “usage limit” on Notion’s data source queries is almost always the SQL allowance in the Notion MCP tool notion-query-data-sources. On Business and Enterprise plans with Notion AI, SQL queries are unlimited. On other plans, workspaces share a metered allowance for single-data-source SQL, and you get an upgrade prompt once it’s used up. Saved-view queries are not metered on any plan.

Two other limits get confused with this one: the general request rate limits (HTTP 429 errors) and a hard cap of 10,000 results per query in the REST API. This guide covers all three, so you can tell which one you’ve hit and what to do about it. Everything here reflects Notion’s documentation and changelog as of October 2026. Notion says these limits can change, so check the linked pages before you build anything that depends on exact numbers.

The three limits at a glance

Limit 1: the MCP SQL usage allowance

Notion MCP’s notion-query-data-sources tool can query a database in different modes. Based on Notion’s Supported tools page and changelog, here is how the modes are metered:

• SQL across one or more data sources is unlimited on Business and Enterprise plans with Notion AI. The changelog says multi-source SQL now works on Business plans with Notion AI, where it used to require Enterprise.
• Single-data-source SQL on other plans draws from a shared, per-workspace usage limit. When that allowance runs out, the tool returns an upgrade prompt.
• Rows mode uses the same allowance as single-data-source SQL.
• View mode (querying a saved view) works on every plan with no tool-specific quota. The changelog notes that existing notion-query-database-view calls still work.

We couldn’t find a published number for the allowance or how often it resets. If you see a figure quoted elsewhere, treat it as unconfirmed unless it links to Notion’s own docs.

What to do if you’ve hit the allowance

1. Check your plan. Look at your workspace plan in Notion’s settings, and check whether it includes Notion AI. The unlimited tier needs both Business or Enterprise and Notion AI.
2. Switch to view mode when you can. If the data you need is already in a saved view (filtered and sorted the way you want), ask your AI client to query that view. View mode isn’t metered.
3. Make each query count. The allowance is shared across the whole workspace, so one teammate’s agent running dozens of exploratory SQL queries uses up budget for everyone. Narrow queries, and save views for questions you ask often.
4. Use the REST API for bulk reads. If you’re building a sync or a report, not having a chat with an agent, the public Query a data source endpoint is the better tool. It has rate limits and a result cap (below), but this SQL allowance doesn’t apply to it.
5. Upgrade only if the numbers justify it. If your team relies on SQL-style questions across several databases, Business with Notion AI is the documented route to unlimited queries.

Limit 2: request rate limits (HTTP 429)

Separately from the SQL allowance, every call counts toward Notion’s request limits. The official Request limits page describes two of them:

• A per-connection limit. Notion’s September 9, 2026 changelog entry, “Faster retries and plan-based rate limits” (mirrored here), moved this to a fixed 60-second window: 600 requests per minute on Business and Enterprise, 180 per minute on all other plans. The maximum Retry-After for this limit dropped from up to 15 minutes to 60 seconds. Per-connection 429 responses now also include the wait time in the body as additional_data.retry_after.
• A per-workspace limit that all of a workspace’s connections share, scaled to the plan. This means you can be rate limited even when your own connection is under its budget.

Older articles describe a flat “three requests per second” average. 180 per minute works out to the same average, but the window and the Business/Enterprise tier are newer, so older posts may be out of date.

MCP search and query no longer have their own rate limits

Notion previously gave notion-search and notion-query-data-sources their own dedicated allowance. The changelog lists 20 search calls and 20 data source query calls per connection every 10 seconds. The October 6, 2026 changelog entry, “No more tool-specific Notion MCP rate limits,” removed that: calls to both tools now count toward the standard request limits, like every other Notion MCP tool.

This change is new, so expect some guides and forum answers to still mention the old 10-second limit.

How to handle a 429 correctly

1. Read the Retry-After header (or additional_data.retry_after for per-connection limits) and wait at least that long before you retry.
2. Treat HTTP 529 the same way. Notion’s docs say it means the service is temporarily overloaded.
3. Check additional_data.rate_limit_reason to see which limit you hit. If it’s the workspace limit, other integrations are using the shared budget too, and slowing down your own client won’t fully fix it.
4. Queue requests rather than firing them in parallel. Sending fewer, larger requests (for example, using filter_properties to return only the columns you need) helps more than retrying aggressively.

Limit 3: the 10,000-result cap on data source queries

This one catches sync jobs out. Notion’s official query-large-data-sources example explains that a single data source query returns at most 10,000 rows, and the limit applies per query, not per data source. A normal pagination loop over a 25,000-row database quietly stops at 10,000 and looks finished.

When you hit the cap, the response shows:

• has_more: false
• request_status.type: "incomplete"
• request_status.incomplete_reason: "query_result_limit_reached"

If your code only checks has_more, it will never notice. Some third-party posts describe this cap as a recent change, but Notion’s docs we found don’t give a date.

How to read every row anyway

The cookbook recommends windowing by creation time:

1. Sort the query by created_time, ascending.
2. Page through with start_cursor until has_more is false.
3. If request_status says incomplete, start a new query filtered to created_time on or after the last row’s timestamp.
4. Repeat until a window finishes without hitting the cap.
5. De-duplicate by page ID, because rows sharing a boundary timestamp show up in both windows.

Use created_time, not last_edited_time. Edit times change, so rows would move between windows and get dropped or counted twice. If more than 10,000 rows share the same created_time (it’s stored to the minute), windows can’t split them, and you’ll need an extra filter on a property that divides your data.

View queries have the same cap but can’t be windowed like this. To read everything behind a view, query the underlying data source and apply the view’s filter and sort yourself.

A note on data source IDs

If you’re working with the REST API and your queries fail rather than hitting a limit, check your API version. Version 2025-09-03 introduced data sources, and queries now go to /v1/data_sources/{data_source_id}/query with a data source ID, not a database ID. Notion’s upgrade guide explains that integrations on older versions can break when a database gets a second data source. That’s a compatibility error, not a usage limit, but it often turns up in the same searches.

Bottom line

If an AI agent using Notion MCP told you you’ve hit a limit and suggested upgrading, that’s the SQL allowance. Use view mode, use the REST API for bulk work, or move to Business or Enterprise with Notion AI. If you’re getting 429s, slow down and respect Retry-After. And if your sync stops at exactly 10,000 rows, check request_status and window your queries by created_time.