NDF File ExtensionAn .ndf file is a SQL Server secondary data file. It stores tables and indexes exactly like the primary MDF does, in the same 8 KB page format. A database always has one MDF and a log, while NDF files are optional extras added to spread the data across more files, more disks or separate filegroups.
File Structure
An NDF is built from the same bricks as the MDF: 8 KB pages, each with a 96 byte header. Rows do not care which file they live in.
Pages are grouped into extents of eight, so SQL Server allocates space in 64 KB blocks. Page 0 of every data file is its file header, which records what the file is and where it belongs. File ids explain the numbering in the diagram above: the MDF is always file 1, file 2 is reserved for the log, so secondary files start at 3.
Because the page format is identical, everything that lives in an MDF can live in an NDF: table rows, index pages, allocation maps and large text or image data. What an NDF does not hold is the system catalog. The tables that describe every object in the database, such as sysschobjs and syscolpars, sit in the primary MDF. That one fact explains most NDF behavior: the primary file is the map and the secondary files are territory.
The File Family
One SQL Server database on disk is a small family of files, each with one job.
| File | Role | How many | What it holds |
|---|---|---|---|
| .mdf | Primary data file | Exactly one | The system catalog that describes every object, plus tables, indexes and data. Read our MDF file guide. |
| .ndf | Secondary data file | Zero or more | More tables, indexes and data in the same page format, usually placed on other disks or in other filegroups. |
| .ldf | Transaction log | One or more | A record of every change, written before the data files. Read our SQL LDF file guide. |
Backups wrap this whole family into a single .bak archive. Our SQL BAK file guide covers that format.
Why NDF Exists
NDF files exist so a database is not chained to one file on one disk. Filegroups are how SQL Server organizes them.
A filegroup is a named container for data files. Every database starts with the PRIMARY filegroup, which holds the MDF. The most common trigger is simple: the disk holding the MDF fills up, so an NDF is added on another drive and the database keeps growing there. Beyond that, administrators add filegroups and place NDF files inside them for a few practical reasons: a huge table can live on its own fast disk, older data can sit on cheaper storage, backups can target one filegroup at a time and writes spread proportionally across the files in a group instead of hammering one disk.
When a table is created on a filegroup, its rows land in that group's files. This is why one database can have rows scattered across several .ndf files and why reading the database back means reading every file in the set, not just the MDF.
Opening the File
An NDF never travels alone. The catalog that names its tables lives in the MDF, so the two open together.
With SQL Server
Attach the database in SSMS with Attach Database or run CREATE DATABASE with FOR ATTACH, listing the MDF and every NDF in its recorded location. All files must be present and healthy, the version must match and you need a running instance with permissions. If a single NDF is missing, the attach fails.
Without SQL Server
Open the primary MDF in the free MDF Viewer and the matching NDF files beside it are reassembled into one database. Every table reads as a whole, including rows that span files, with no instance, no ATTACH and no matching version needed.
One thing to know before double clicking: opening an .ndf on its own shows pages without a map, because the object names sit in the MDF catalog. Keep the family together in the same folder so any reader that understands the format can put the pieces back in order.
When Things Break
Because the MDF records every file in the set, a problem with one NDF can take the whole database down.
The NDF is missing
A file was moved, deleted or lost with its disk. SQL Server refuses the attach because part of the data is gone. A binary reader still opens the MDF and recovers everything in the files that survive.
The NDF is corrupt
Torn or damaged pages in a secondary file can mark the database suspect. MDF Repair reads the whole file set page by page, skips the damage and rebuilds every reachable row.
Rows were deleted
Deleted rows sit in unallocated pages until the space is reused. Those pages can be in an NDF just as easily as the MDF. Recovery reads them wherever they live in the file set.
The Tools
Univik reads the whole file family at the page level, so the data is yours even when no server is running.
MDF File Viewer
Open the MDF free and browse every table, with the matching NDF files reassembled automatically. A clear look at the data with no SQL Server.
Open the ViewerMDF Repair
A corrupt MDF or NDF blocks the whole database. The repair reads the file set page by page and rebuilds every table it can reach.
Repair the FileSQL Database Recovery
The wider rescue for a damaged database: suspect files, deleted records and dropped tables across MDF, NDF and BAK.
Recover a Database Help & Support
An NDF file is a secondary data file in a SQL Server database. It stores tables and indexes exactly like the primary MDF does, in the same 8 KB page format. A database has one MDF and one or more LDF log files, while NDF files are optional extras added to spread the data across more files or disks.
The MDF is the primary data file and holds the system catalog plus data. NDF files are optional secondary data files that hold more data. The LDF is the transaction log that records every change. Together they make up one database.
No. A new database gets one MDF and one LDF by default. NDF files exist only when someone adds them, usually to spread a large database across disks or to organize it with filegroups.
Yes, with a binary reader like Univik. Open the primary MDF and the matching NDF files beside it are reassembled into the full database, with every table readable and no SQL Server installed.
Not meaningfully. The system catalog that names the tables and columns lives in the primary MDF, so an NDF alone is pages without a map. Open the MDF and its NDF files together to read the data properly.
In SQL Server, use ALTER DATABASE with ADD FILE and give the new file the .ndf extension, optionally placing it in a filegroup. The extension itself is a convention, but keeping .ndf makes the file's role obvious.
Never delete it from disk directly, because the database will fail to attach or go suspect without it. The safe path inside SQL Server is to empty the file first with DBCC SHRINKFILE using EMPTYFILE, then remove it with ALTER DATABASE REMOVE FILE.
Yes. Univik reads the MDF and NDF files at the page level, reassembles data that spans files and reads past damaged pages. Deleted rows sitting in NDF pages are recovered the same way as rows in the MDF.
The primary MDF records every file that belongs to the database. When a listed NDF is missing, SQL Server refuses the attach because part of the data is gone. A binary reader can still open the MDF and recover everything stored in the files that survive.