You build an inspection app inside Teams in an afternoon. The tables are real tables. The lookups work. It cost nothing. Eight months later someone in finance asks for access, and you find out they can’t open it.
Dataverse for Teams is free and relational, so it’s easy to assume there’s no catch. There are three. None of them show up while you build. They show up later, when the storage meter climbs, when someone outside the Team asks for access, or when a manager wants the data in another system.
The app itself is usually fine. It’s on the wrong back end for the people who end up using it.
The wrong diagnosis
The question usually gets framed as “free database versus free list”, which treats Dataverse for Teams as a smaller copy of Dataverse. It’s a separate product. Where full Dataverse has a door (more storage, an API, a wider audience), Dataverse for Teams has a wall.
So the useful question is which wall this particular app will hit first. Every app hits one eventually. The two back ends have different walls, and climbing one costs far more than climbing the other.
Why Dataverse for Teams looks like the default
Microsoft introduced Dataverse for Teams in September 2020. It comes with select Microsoft 365 plans. The first time someone in a Team builds an app with Power Apps inside Teams, that Team gets its own environment, automatically, with no admin involved. That ends on November 15, 2026, when Microsoft stops creating new Dataverse for Teams environments. I cover the full deprecation timeline in a separate post.
Inside it you get real tables. Lookups between them. Choice columns. File and image columns. A canvas app that deploys to the Team with one click. For a maker who has fought SharePoint lookup columns, this feels like the grown-up option.
It’s a good product. The trouble is the scope, which is one Team, and everything below follows from that.
Ceiling one: 2 GB per Team, and you can’t buy more
Each Dataverse for Teams environment gets 2 GB of combined database and file storage. Part of that is reserved for the system. Microsoft’s own estimate is about 1 million rows of typical data.
That sounds like a lot. It isn’t, for two reasons.
First, files count. An inspection app that attaches two photos per record isn’t really storing rows. It’s storing photos, and photos fill 2 GB long before rows do.
Second, there’s no top-up. Microsoft’s licensing FAQ asks itself whether customers can purchase more capacity for a Dataverse for Teams environment, and the answer it gives is no.
Here’s what happens as you approach the limit:
- At 80 percent, makers see a warning inside the Teams build experience.
- At 100 percent, existing apps, flows and agents keep working and can still be updated, but no new app, flow, agent or table can be created or installed in that environment.
There’s also a tenant-wide count. Every tenant gets 5 environments, plus one more for every 20 eligible Microsoft 365 licences. A 100-person organization gets 10. That’s 10 Teams that can ever have an app with a Dataverse for Teams back end, unless an admin deletes or upgrades one.
Environments per tenant
Each step is 20 more licences. Every environment is one Team, and one Team is the most an app can reach without extra sharing. Checked in October 2026 against Microsoft Learn.
Ceiling two: the Team boundary
Access to a Dataverse for Teams environment is restricted to the Team it belongs to. The Microsoft 365 group behind the Team is bound to the environment, and that binding can’t be edited until the environment is upgraded.
In practice:
- Team members can run every app and read and write every record. Members also get full maker rights, so anyone in the Team can edit the app.
- Team guests can run apps, but by default they only see records they created.
- Everyone else in your tenant can’t see the app at all.
There’s a way to reach people outside the Team. A team owner can use Share with colleagues, which assigns one security group to a role called Colleagues with access. The group must have the membership type Assigned, and the default size limit is 10,000 members. Then, table by table, the owner sets what that role can do: full access, collaborate, reference, or private.
That works, but look at what you have just taken on: a second permission model, managed from inside Teams, by whoever happens to own the Team. Colleagues with access land in the environment as a Basic User with no data access until someone grants it per table. And the moment the first colleague is added, the Microsoft 365 group binding is dropped to let them in, so the tidy “one Team, one environment” story is gone anyway.
Two more boundaries sit under this one. The apps don’t appear in the Power Apps maker portal or in the Power Apps mobile app list; they run through Teams. And there’s no API access. Only apps, flows and agents running inside Teams can reach the data. No webhook, no SQL connection, no auditing, no field-level security. All of those are full Dataverse features.
Where a SharePoint list still wins
A list is the plain option, and for a lot of apps plain is exactly right.
Start with reach. Anyone with permission on the site can open the app. Put the list on a communication site and the whole organization can get to it, with no security group, no owner-managed sharing, and no per-table grants. The permission model is the one your SharePoint admin already runs.
Then room. A list holds up to 30 million items, and each item can carry attachments up to 250 MB. Storage comes out of the tenant’s SharePoint pool, which grows with every licence you buy and can be topped up when it runs low.
The exit is cheap. If a list app outgrows its list, you fix the queries, split the list, or move the rows somewhere else, and no licence changes hands. When a Dataverse for Teams app outgrows its environment, the exit is a licence conversation for every user.
And the files are usually already there. A lot of these apps wrap a process that already lives in SharePoint: a request form, an asset register, a visitor log. A list keeps the data beside the documents, where Power Automate, search, and Copilot can all see it.
The SharePoint list’s own wall: delegation
A list has a limit too. It’s a limit on the shape of your queries rather than on row count, and it bites quietly.
Power Apps tries to hand each query to the data source so the source does the filtering. That’s called delegation. When a query uses something the source can’t handle, Power Apps pulls the first 500 records to the device and filters those. You can raise that to 2,000 in the app settings. You can’t raise it further.
The failure is silent. A filter that can’t be delegated doesn’t error. It returns the right answer on a small list and the wrong answer on a big one, because record 501 was never fetched. The maker sees a blue underline in the formula bar and a yellow triangle on the control, and most makers click past both.
SharePoint delegates the common operations: equals, filters and sorts on text, number and date columns, lookups, StartsWith on text. It doesn’t delegate everything. Microsoft keeps a table of what does and doesn’t delegate for SharePoint on the connector page, and it’s worth ten minutes before you commit a design. I didn’t build a test app for this post, so the limits here come from Microsoft’s documentation rather than my own tenant.
The practical rule: keep “find my record” queries to equals and StartsWith on indexed columns, and keep the list under a few tens of thousands of items. Inside that envelope, a list is a fine back end. Outside it, delegation is a real wall, and that’s the real case for Dataverse for Teams.
Rows before each wall
Log scale, so each gridline is ten times the last. The short blue bars are the real SharePoint wall: what a filter Power Apps can't delegate actually sees. Checked in October 2026 against Microsoft Learn.
Side by side
| At a glance | SharePoint list | Dataverse for Teams |
|---|---|---|
| Who can open it | Whole site Anyone with site permission | One Team Plus one shared security group |
| Size ceiling | 30 million items 250 MB per attachment | 2 GB About 1 million rows, files count |
| Relationships | Lookup columns Delegate only partly | Real tables Proper relationships |
| What stops you first | Delegation 500 rows, 2,000 at most | Storage No new apps at 100 percent |
| API and reporting | Graph, REST, Power BI Plus Power Automate | None outside Teams No API, webhooks or SQL |
| Cost to outgrow it | Nothing Fix the queries or move the rows | A licence per user Power Apps Premium, CAD $27.10 a month each |
Strong on this point A limit to plan for
Moving off Dataverse for Teams if you outgrow it
The catch nobody mentions while you’re building is that there’s no export.
Microsoft’s licensing FAQ, asked whether a solution built in Dataverse for Teams can be packaged and imported into a full Dataverse environment, answers that the capability isn’t available yet and is included in our roadmap. That leaves two ways out:
- Upgrade the environment in place. A tenant admin does it in the Power Platform admin centre. The tenant must already have at least as much free Dataverse capacity as the environment is using, or the upgrade is blocked. After the upgrade, the environment’s lifecycle is no longer tied to the Team, the storage counts against the tenant’s Dataverse pool, and every user of every app in it needs a Power Apps licence. Power Apps Premium lists at CAD $27.10 per user per month, paid yearly, so a 40-person app costs about CAD $1,084 a month.
- Rebuild. Export the data table by table, create the tables again in the new home, point a new app at them. For a small app this is a day. For an app with a year of history and photos, it’s a project.
Neither is cheap, which is why this decision belongs before the first table is created.
What this doesn’t fix
This post doesn’t help if the real answer is full Dataverse from day one. An app that will be used across the organization, needs an audit trail, feeds Power BI, or will grow past 2 GB in its first year is a Dataverse app with a licence line. Dataverse for Teams was never a free version of that, and a SharePoint list only postpones the conversation.
It also doesn’t rescue a SharePoint list that has been used as a relational database. Six lookup columns, a filter on each, and 60,000 rows is a list app that’s likely to return incomplete results, however carefully you index. The fix there is to move the data, not tune the formulas.
It doesn’t cover model-driven apps, which don’t run on Dataverse for Teams at all, or people outside your tenant, where both options get harder in different ways.
And it doesn’t replace a test. Build a two-screen prototype on both back ends, 50 rows each, in one afternoon. Then put a real filter on each and watch for the delegation warnings. That afternoon will tell you more about your own data than this post can.
The bottom line
Before you create the first table, write down who will open the app in a year and the three filters users will run most. One Team and relational data points to Dataverse for Teams; the whole organization and simple filters point to a SharePoint list. If either answer involves an API, an audit trail or more than 2 GB, price full Dataverse now, because rebuilding later costs more than starting there.