A .bacpac is a SQL Server database packed into one portable file: the full schema plus all table data, stored inside a ZIP archive. Its main job is moving a database between servers, most often between on premises SQL Server and Azure SQL Database. It looks like a backup but it is not one. That difference matters.
File Structure
Rename a .bacpac to .zip and open it. There is no magic inside, just a tidy package of schema and data.
The schema in model.xml is plain XML you can read in any editor. The rows are a different story: each table is stored as BCP native format files, the same binary stream SQL Server's own bulk copy uses. Every value is written in the engine's internal encoding, which is why a text editor shows gibberish and why the format round trips into SQL Server byte for byte.
This split explains the format's character. A .bacpac is a logical export: instructions to recreate the objects, plus the data to refill them. Nothing inside is a copy of the original database's pages, which is exactly where the BAK comparison begins.
The Three Packages
Three SQL Server package formats with confusingly similar names and completely different jobs.
| Question | .bacpac | .dacpac | .bak |
|---|---|---|---|
| What is inside? | Schema plus all table data, bulk copied | Schema only by default, no rows | A page level copy of the data files and log |
| Physical or logical? | Logical export | Logical definition | Physical backup |
| Main job | Move a database, especially to or from Azure SQL | Deploy or compare schema versions | Protect a database, restore to a point in time |
| Transactionally consistent? | Only if nothing writes during export | Not applicable, no data | Yes, always |
| Restores into | A new database only | A new or upgraded schema | The same database, exactly as it was |
Microsoft is direct about the boundary: BACPAC files are not intended for backup and restore. For the physical format on the other side of that line, read our SQL BAK file guide.
The logical format hides one superpower a BAK will never have: version freedom. Because a BACPAC is scripts and data rather than pages, a database exported from SQL Server 2019 imports happily into SQL Server 2016, while a BAK only restores to the same version or newer. Stuck with that BAK problem on a raw data file? Our guide to opening a higher version MDF on an older SQL Server covers the same wall. The open ZIP structure also makes a BACPAC a reasonable way to archive a database for the long term, readable years later without the original server.
Export
Three official routes from a live database and one route that needs no database at all.
From a live database
In SSMS, right click the database and choose Tasks then Export Data-tier Application. From the command line, run SqlPackage with the Export action. In Azure, use the Export button on the database page. All three bulk copy every table into the package, so export when the database is quiet or work from a snapshot to keep the data consistent.
From an offline MDF file
When all you have is the .mdf and the server is gone, Univik MDF Converter reads the file at the binary level and exports tables to a .bacpac directly, writing the same BCP native data streams the SQL Server tools write. No instance, no ATTACH and no SqlPackage.
Import and Open
Importing rebuilds the database. Opening just looks inside. Both are useful, for different reasons.
Import into SQL Server or Azure
In SSMS, right click Databases and choose Import Data-tier Application. From the command line, run SqlPackage with the Import action. In the Azure portal, use Import database. The import always builds a new database, first creating the schema from model.xml and then bulk loading the data.
Open it as an archive
Because a .bacpac is a ZIP, any archive tool opens it. That is enough to read the schema in model.xml or check which tables are present. The rows themselves sit in binary BCP files, so browsing actual data takes a tool that speaks the format.
Know Before You Rely On It
The format is honest about what it is. These four facts save the most surprises.
It is not a backup
The data is bulk copied table by table, not captured at one point in time. A busy database can export inconsistent data. BAK exists for protection. BACPAC exists for moving.
New database only
The import cannot load into an existing database. It keeps the collation and compatibility level but not the physical layout, so filegroups and file sizes are not reproduced.
Logins lose passwords
SQL Server authentication logins come across without their passwords for security. Plan to reset credentials after the import lands.
Size has a comfort zone
Microsoft suggests SqlPackage over the portal service for databases larger than about 150 GB and notes temp space can reach three times the database size during the run.
Compressed, not encrypted
The ZIP shrinks the data but nothing inside is encrypted, so every row travels readable. Treat a .bacpac with the same care as the database it came from.
The Tools
Univik reads the database formats at the binary level, so a missing server never blocks the data.
MDF File Converter
Open an MDF with no SQL Server and export its tables to .bacpac, SQL script, CSV, Excel and more, then restore them to a live server.
Open the ConverterSQL BAK Converter
Open a .bak backup without RESTORE, browse the tables inside and export them, even when the backup is compressed.
Open the BAK ConverterMDF File Viewer
Look inside an MDF free before exporting anything: browse tables, check schema and preview records with no conversion.
Open the Viewer Help & Support
A BACPAC file is a SQL Server database packed into one portable file: the full schema plus all table data, stored inside a ZIP archive with a .bacpac extension. Its main job is moving a database between servers, most often between on premises SQL Server and Azure SQL Database.
A DACPAC holds only the schema by default: tables, views, procedures and other object definitions with no rows, though data can be included at extract. A BACPAC holds that same schema plus all of the data. Deploy a DACPAC to create or upgrade an empty structure and use a BACPAC to move a full database.
A BAK is a physical backup: an exact page level copy of the database with its log, restored by SQL Server as a transactionally consistent whole. A BACPAC is a logical export: schema scripts and bulk copied table data. Microsoft states that BACPAC files are not intended for backup and restore. Use BAK to protect a database and BACPAC to move one.
From a live database, right click it in SSMS and choose Tasks then Export Data-tier Application. You can also run SqlPackage with the Export action or use the Export button in the Azure portal. From an offline MDF file, Univik MDF Converter writes the .bacpac directly with no SQL Server involved.
In SSMS, right click Databases and choose Import Data-tier Application. You can also run SqlPackage with the Import action or use Import database in the Azure portal. The import always creates a new database. It cannot load a BACPAC into an existing one.
Yes. A .bacpac is a ZIP archive, so any archive tool opens it. Inside you will find model.xml with the schema, Origin.xml with export metadata and a Data folder holding each table as BCP native files. The BCP data is binary, so reading actual rows takes a tool that understands the format.
Only if nothing writes to the database during the export, because the data is bulk copied table by table rather than captured at one point in time. Microsoft recommends exporting from a transactionally consistent copy, such as a database snapshot, when the source is busy.
Yes. Univik MDF Converter reads the MDF at the binary level and exports tables to a .bacpac, writing the same BCP native data streams the SQL Server tools write. No instance, no ATTACH and no SqlPackage is needed, which helps when the original server is gone.
The import creates a new database only and keeps the collation and compatibility level but not the physical layout, so filegroups and file sizes are not reproduced. SQL logins come across without their passwords. Microsoft also suggests SqlPackage over the portal service for databases larger than about 150 GB.