3.1 Dataverse vs Traditional Databases; Tables, Columns, Relationships

Microsoft Dataverse is the data platform that underlies most of what you build in Power Platform. Whether you are creating a canvas app, a model-driven app, a Power Automate flow, or a Copilot Studio agent, the data those tools read and write commonly lives in Dataverse. The Manage the Environment domain of PL-900 accounts for 20-25% of the exam, and Dataverse fundamentals are the largest single topic inside it — expect several questions on tables, columns, relationships, and how Dataverse differs from a database you might build yourself.

What Is Microsoft Dataverse?

Dataverse (formerly the Common Data Service, or CDS) is a secure, cloud-based data storage and management platform built into the Power Platform. It stores and manages the data used by business applications, and it is the shared data layer behind Power Apps, Power Automate, Power Pages, Copilot Studio agents, and Dynamics 365 apps such as Sales, Customer Service, and Field Service.

Because Dataverse is a managed platform rather than a database you administer yourself, Microsoft handles the underlying infrastructure — patching, scaling, backups, and high availability — while makers and admins focus on modeling data and building logic on top of it.

Dataverse vs. Traditional Databases

A traditional relational database (for example, a self-hosted SQL Server instance) gives you raw storage and requires a database administrator or developer to add security, business logic, and integration on top. Dataverse bundles those capabilities in from the start:

This is the core PL-900 distinction: Dataverse is not just storage, it is storage plus built-in security and logic that would otherwise need to be built by hand.

Tables: Standard and Custom

A table (the current term for what was historically called an "entity") is a set of rows and columns used to store data, similar to a table in a database. Dataverse ships with standard tables that model common business concepts out of the box, including Account, Contact, Lead, Opportunity, and Task. Makers can also create custom tables to model data specific to their organization, such as Equipment, Reservation, or Incident. Using standard tables where possible saves modeling effort and gets you built-in relationships, forms, and views for free; custom tables fill the gaps that standard tables do not cover.

Columns and Data Types

A column (formerly "field") stores a single piece of data on a table, such as a name, an amount, or a date. Every column has a data type that constrains what it can hold:

Every table also has a primary column, a required text column (often the name) that uniquely identifies each row when it appears in lookups, views, and search results.

Relationships Between Tables

Tables rarely stand alone — a Contact belongs to an Account, an Order references a Customer, and so on. Dataverse models these connections through relationships, built using lookup columns:

• One-to-many (1:N): One row in a table can relate to many rows in another table. For example, one Account can have many related Contacts. From the Contact's perspective, this is a many-to-one (N:1) relationship back to Account.
• Many-to-many (N:N): Rows in one table can relate to many rows in another table, and vice versa. For example, many Students can enroll in many Courses, and many Courses can have many Students.

A lookup column is what implements a 1:N relationship on the "many" side — it is a column on the child table that points to a single row on the parent table. Recognizing that a lookup column is how a one-to-many relationship is expressed in the schema is a common exam distinction, since the lookup itself is what a maker adds when connecting two tables.

Key Takeaways

• Dataverse is the managed data platform behind Power Apps, Power Automate, Power Pages, Copilot Studio, and Dynamics 365
• Unlike a traditional database, Dataverse ships with built-in security, business logic, and native Power Platform integration
• Tables can be standard (Account, Contact) or custom; every table has a required primary column
• Columns have data types — text, choice, number, date, lookup, yes/no, and more
• Relationships (1:N, N:1, N:N) connect tables and one-to-many relationships are implemented through lookup columns