You know this meeting. Someone from finance or operations says "we need a single source of truth for our reference data." There's some talk about data quality, governance, maybe a consultant mentions "golden records." Then your manager turns to you and says: "You're the database person — can you look into this?"
That's how most SQL Server DBAs end up in the MDM world. Not by choice, but by proximity to the database. And the first thing you discover is that every vendor in this space speaks a different language than you do. They talk about "data stewardship frameworks" and "governance ontologies" while you're wondering which tables get created and whether you need to babysit another service.
This guide is different. It's written for someone who thinks in tables, indexes, and stored procedures — because that's exactly what MDM boils down to when you strip away the consulting jargon.
What MDM actually means (in DBA terms)
Strip away the buzzwords and master data management is this: a single, authoritative database for your organization's reference data. Customers, products, branches, cost centers, suppliers — the stuff that every other system points to but nobody owns.
Right now, that data probably lives in a dozen places. Your ERP has a customer table. Your CRM has a different one. Finance maintains their own list in a spreadsheet someone emailed around in 2019. When someone asks "how many active customers do we have," you get three different numbers depending on who you ask.
MDM gives you one place where that data is defined and maintained. Other systems can consume it via views, APIs, or direct queries. When a branch code changes or a product gets discontinued, it changes in one place and flows everywhere.
If you've ever built a lookup table that three applications share — congratulations, you've done MDM. You just didn't call it that.
Why the DBA always gets this job
There's a reason this lands on your desk and not in application development or the BI team. Master data is fundamentally a database problem. It's about data integrity, referential consistency, unique constraints, and controlled change. Those are DBA concepts — and they're the foundation of any serious data governance program.
The business side adds a layer on top — who can edit what, approval workflows, audit trails, but underneath it all, you need tables, indexes, and stored procedures that enforce the rules. An MDM tool that doesn't respect that reality is an MDM tool that will give you headaches.
So, about Microsoft MDS.
"What about Microsoft MDS?"
If you're a SQL Server DBA, someone has probably already mentioned Master Data Services. Maybe you even have it installed. Microsoft included MDS with SQL Server Enterprise and Standard editions for years — it felt like the obvious choice.
The problem: Microsoft removed MDS from SQL Server 2025. Completely. It's not deprecated — it's gone. If you're running MDS today, you're on borrowed time. SQL Server 2022 extended support ends in 2032, but the writing is on the wall. (We wrote a full post on why MDS failed if you want the details.)
And honestly? Even before the removal, MDS was painful. The web UI was built on Silverlight (which Microsoft themselves killed in 2021). The Excel add-in was the only usable interface, and it broke regularly. The data model was rigid. The terminology was confusing — "derived hierarchies," "explicit hierarchies," "subscription views." Most MDS deployments we've seen are half-abandoned, maintained by the one person who figured out how to use it.
So if you're evaluating MDM for the first time or looking for an MDS replacement — you need a different approach.
What a DBA actually wants from an MDM tool
We've talked to dozens of DBAs about this. The wishlist is always the same:
Not a cloud-only SaaS. Not a separate database engine. The data lives in a SQL Server database you control, back up, and query directly.
Business logic belongs in the database. You want to see the procedures, understand the transaction handling, and be able to troubleshoot without reading application code.
Open SSMS, browse the tables, understand exactly what's stored where. Done.
Backup/restore, Always On, replication, SQL Agent jobs — your existing maintenance plans should just work. The MDM tool shouldn't fight your infrastructure.
Integration views, direct SELECTs, linked servers — whatever your downstream systems need. Not everything has to go through an API.
No Java application servers, no Elasticsearch sidecars, no Kubernetes clusters. Install it, point it at SQL Server, go.
Most enterprise MDM platforms fail at least three of these. They want you to hand over control to their stack. That's fine for a Fortune 500 with a dedicated MDM team. It's a non-starter for a DBA who's also managing six production databases and an SSIS package that hasn't been touched since 2017.
Under the hood: how Primentra stores master data
Alright, let's look at the actual schema. Here's the architecture the way I'd explain it to another DBA over coffee.
Primentra uses an EAV (Entity-Attribute-Value) model backed by SQL Server 2016+. If you've worked with systems like Magento or Dynamics CRM, you've seen this pattern before. The trade-off: you get complete flexibility in defining entities and attributes at runtime, but querying requires pivots.
The core tables
Eleven tables. That's it. Here's the schema that matters for data storage:
| Table | Purpose | Key detail |
|---|---|---|
| Models | Top-level grouping | Think: "HR", "Finance", "Supply Chain" |
| Entities | A data domain within a model | Think: "Branch", "Customer", "Product" |
| Attributes | Column definitions per entity | Data types: Text, Int, Decimal, DateTime, Domain, Boolean |
| EntityRows | One row per master data record | Code (UNIQUE per entity) + Name — your business key |
| EntityValues | EAV value storage | Typed columns: TextValue, IntValue, DecimalValue, DateTimeValue, DomainValue |
The EntityValues table is the workhorse. Each attribute value is stored in a typed column — no casting strings to everything. An integer is stored as IntValue INT, a date as DateTimeValue DATETIME2, and a domain reference (a foreign key to another entity's row) as DomainValue BIGINT.
Indexes that actually matter
The EAV pattern gets a bad reputation for performance, usually because people forget to index it properly. Primentra ships with a covering index on EntityValues that eliminates key lookups on the most common query pattern:
Plus a filtered index on domain references for fast FK resolution:
You'll find the UNIQUE (EntityId, Code) constraint on EntityRows — Code is the business key. Import and deduplication logic keys off of this. If two source systems send records with the same Code, the stored procedure knows they're the same record.
105 stored procedures, zero raw SQL
Here's where Primentra is unusual for a web application. Every single database operation goes through a stored procedure. The API layer is a thin pass-through — it calls a proc, returns the result. No ORM. No query builder constructing SQL strings at runtime. No application-side transaction management that you can't see from SSMS.
All procedures follow the usp_ naming convention. Here's what the landscape looks like:
Transactions are handled inside the procedures, not from the application. Each proc that writes data uses an "own transaction" guard pattern:
That means a single-row save commits its own transaction, but when the API runs a batch import (looping usp_Data_SaveRow inside a larger transaction), the proc defers commit to the caller. No partial writes. If row 47 out of 200 fails validation, everything rolls back.
For the DBA, this means: you can trace, profile, and debug every operation from SSMS. Extended Events, SQL Profiler, Query Store — all your usual tools work, because the work is happening in SQL Server, not hidden inside an application layer.
Want to browse the full stored procedure reference and database schema? See the technical documentation.
Integration: views you can actually SELECT from
EAV is great for flexibility, terrible for ad-hoc querying. You don't want your reporting team writing five-way JOINs to get a flat table of branch data. Primentra solves this with integration views — real SQL Server views that are auto-generated and deployed directly to the database.
You configure an integration view in the UI (pick an entity, choose which columns to include, select flat or hierarchical), and Primentra runs usp_IntegrationView_Deploy — which creates or replaces a real CREATE VIEW in your database. Power BI, SSIS, linked servers, SSRS — anything that can query SQL Server can read from it.
Hierarchical views automatically join domain attributes, giving you denormalized output with columns like Area_Code, Area_Name, Zone_Code next to the branch data. No manual JOINs required.
That's what integration should look like. Not a REST API that your SSIS package has to call with a Script Task. A view. In your database. That you can join to other tables.
What about backup, HA, and maintenance?
Since Primentra lives in a standard SQL Server database called Primentra, your existing infrastructure just works:
Standard FULL + DIFF + LOG backups. Your existing maintenance plans cover it. Nothing proprietary to worry about.
The Primentra database participates like any other user database. Add it to your AG, set up log shipping — standard procedures.
Ola Hallengren's scripts, AzureSQL Maintenance, whatever you use. The covering index on EntityValues will fragment — rebuild it on your regular schedule.
Query Store, Extended Events, sp_WhoIsActive — all work normally. Stored procedures show up by name in your traces, not as parameterized ad-hoc queries.
That's the advantage of building on SQL Server instead of around it. You won't be backing up a separate data store or babysitting an external search engine. It's one database. Your database.
Audit trail and data governance (your compliance team will love this)
Every create, edit, delete, import, and purge operation is logged to the AuditLog table with a full JSON snapshot of the affected data. The before-and-after state is captured, so you can always answer "who changed this, when, and what did it look like before?"
The audit log is stored in the same database. No separate logging infrastructure. You can query it directly, export it, build reports on it, or feed it into your existing SIEM or compliance tooling via a view.
Cleanup is handled by usp_AuditLog_Cleanup — schedule it via SQL Agent if you don't want unbounded growth. The default retention is configurable. This is the kind of operational detail that enterprise MDM vendors bury three levels deep in their admin console. Here, it's a stored procedure you can call from a job.
Getting started: what "install" actually looks like
No MSI wizards. No service accounts. No IIS configuration with six authentication modes. Here's the actual process:
Point Primentra at your SQL Server instance (hostname, instance name, credentials)
Click "Setup Database" — this runs the setup script that creates the Primentra database, all tables, indexes, and stored procedures
Create your first model and entities in the web UI
Start entering data — or import it from Excel, JSON, or your existing MDS instance
The setup script uses CREATE OR ALTER for all stored procedures, so it's idempotent — you can run it again on updates without dropping anything. If you're migrating from Microsoft MDS, there's a built-in migration wizard that reads your MDS models, entities, and data and maps them into Primentra's structure.
Minimum requirement: SQL Server 2016. That's it. No Enterprise edition needed — Standard or even Express works for smaller deployments. The only SQL Server 2016+ features used are OPENJSON, STRING_SPLIT, and CREATE OR ALTER.
When Primentra is NOT the right fit
Let's be honest about the edges. Primentra is built for reference data management — maintaining clean, governed lists of entities like branches, products, customers, cost centers, and their relationships. It's not:
A match-merge engine. If you need probabilistic entity resolution across millions of customer records with fuzzy matching and survivorship rules, you need Informatica MDM or Reltio.
A data catalog. If your primary need is discovering what data exists across your organization and tracking lineage, look at Collibra or Alation.
A real-time CDC pipeline. Primentra is a system of record, not a change data capture stream. You query it, you don't subscribe to it (yet).
If your organization needs to manage reference data — the kind of data that lives in lookup tables, feeds dropdown menus, and drives business rules across systems — that's the sweet spot. And for that job, paying six figures for an enterprise platform is like hiring a Formula 1 pit crew to change the oil on your commuter car.
The bottom line for DBAs
Master data management doesn't have to be an enterprise odyssey. If you're a SQL Server DBA, you already have most of the skills. You understand data integrity, referential constraints, and why transactions matter. What you need is a tool that respects those skills instead of hiding everything behind a proprietary layer.
Primentra gives you a database you can inspect and stored procedures you can trace. The views are queryable. The audit trail is just another table. It runs on the SQL Server you already manage. Your backup jobs cover it. Your team already knows the tools.
MDM, built for the people who actually run the databases. That's it.
Want to inspect the schema yourself? Explore the full database schema and stored procedure reference, or try Primentra free for 60 days on your own SQL Server.
- No cloud migration — stays on your own SQL Server
- No professional services required — self-service from day one
- No credit card for the trial