The Microsoft Access 2GB Limit Explained: What Actually Happens When You Hit It
Microsoft Access limits every database file to 2GB. The limit applies per file rather than per application, so a split database gets 2GB for its front end and 2GB for its back end, counted separately. The limit is a property of the .accdb and .mdb file formats and cannot be raised by configuration.
The usual declaration before we go further: I rebuild Microsoft Access databases as web applications for a living, so the last of the four ways out at the end of this post is the one I sell. The first three involve no work from anyone like me, and for plenty of databases one of them is the right answer.
This ceiling is a different kind of problem from the end-of-support deadline I wrote about recently. That one arrives on a date Microsoft chose, and when it arrives nothing visibly changes. This one arrives on a date your data chooses. When it arrives, things genuinely stop working, usually without a polite warning first.
What the 2GB limit actually is
Microsoft's own Access specifications page states the limit as 2 gigabytes, minus the space needed for system objects, for the total size of one database file. It applies to the current .accdb format and to the older .mdb format alike. There is no registry key, no setting and no edition of Access that raises it: it is baked into how the file format addresses its own pages, which is why the number has not moved in decades.
The most useful and least-known nuance is what the limit does not apply to. It is a per-file limit, not a per-system limit. If your database is split (a front-end file holding the forms, queries, reports and VBA, linked to a back-end file holding the tables), each file gets its own 2GB. That is not a combined 4GB pot; it is two separate meters, and in practice the back end is the one that fills. Microsoft's specifications page notes the same principle as a workaround: a database can link to tables in other Access files, each of which may itself grow to 2GB. And data held in a linked SQL Server or MySQL back end does not count against the Access file at all. Only what is stored inside the .accdb or .mdb itself does. If you are unsure whether your database is split, I cover how to check in the diagnostic near the end.
The 2GB ceiling sits inside a family of fixed limits worth seeing together:
| Specification | Limit |
|---|---|
Database file size (.accdb / .mdb) |
2GB, minus space needed for system objects |
| Single table size | 2GB, minus space needed for system objects |
| Fields per table | 255 |
| Concurrent users | 255 |
| Objects per database | 32,768 |
| Indexes per table | 32 |
| OLE Object field | 1GB |
| Long Text field | 65,535 characters via the interface; 1GB entered programmatically |
Verified against Microsoft's Access specifications on August 15, 2026.
Why does the file hit 2GB long before your data does?
An Access database routinely reaches 2GB while holding far less than 2GB of actual data. Deleted records are not released until the file is compacted, temporary query workspaces consume space during execution, and embedded attachments and OLE objects are stored inline. In practice, attachments are the most common single reason a business database approaches the ceiling.
That paragraph is the short answer to the question I hear most: "my data is nowhere near 2GB, so why is the file?" Here are the four mechanisms, in the order I usually find them.
Deleted records do not free space until you compact
When a record is deleted, Access marks its space as reusable inside the file; it does not shrink the file. A database that has churned through years of imports, purges and re-imports carries all of that history as dead weight. The file only ever grows between compacts. Deletion never makes it smaller.
Temporary objects, query workspaces and sort space count
Every large query, sort and crosstab needs working space, and Access takes that space inside the same file. Run a heavy report against a file sitting at 1.9GB and the temporary workspace alone can push it over the edge, which is why the failure so often happens during month-end reporting rather than during ordinary data entry.
Embedded attachments and OLE objects are the usual culprit
Attachment fields and OLE Object fields store the file itself inside the database: the scanned delivery note, the signed PDF, the product photo. One modest scan per record, a few thousand records, and the embedded documents can outweigh the actual data many times over. In the databases I am asked to look at, embedded files are the single most common reason for a 2GB emergency, and OLE objects are the worst offenders because older versions stored uncompressed bitmap renderings alongside the file.
Indexes, and why over-indexing costs more than people expect
Every index is stored in the file, and Access quietly creates indexes of its own to maintain relationships. A wide table with an index on every searchable column, plus the automatic ones, can spend a surprising share of its size on index pages. Indexes earn their keep on genuinely searched columns; on everything else they are pure weight that also slows every insert.
What actually happens when you reach it?
When a Microsoft Access database reaches the 2GB limit, writes fail with errors that rarely mention size, and an interrupted write can leave the file in a state Access reports as corrupt. There is no tidy "database full" dialog. The sequence I see most often starts weeks earlier: saves get slower, compacts take longer, and the file hovers somewhere above 1.8GB. Then the errors begin. Users report "Invalid argument" on inserts, or "There isn't enough disk space or memory" on a machine with half a terabyte free. Push further and the file can fail to open at all, with Access reporting an unrecognised database format or a file that "may be corrupt".
That is the important point: the failure at the ceiling is corruption-shaped, not quota-shaped. A write that cannot complete because the file cannot grow can leave the file in a state Access no longer fully understands. That is why the first casualty of the 2GB limit is often not new data but confidence in the existing data.
It is also why the last-good-backup question suddenly matters enormously. If your backup routine copies the live file every night, then last night's backup is a copy of a file that was already at the ceiling, and possibly already damaged. Before you do anything else to a database near 2GB, take a copy, confirm that the copy actually opens, and confirm you can read the tables you care about. A backup nobody has ever restored is a hope, not a backup.
Compact and Repair: what it buys and what it doesn't
Compact and Repair (Database Tools → Compact and Repair Database) rebuilds the database into a fresh file, writing back only what is live: real records, real objects, rebuilt indexes. Everything from the first half of this post is discarded: dead space from deletions, leftover temporary workspaces, fragmented pages. On a long-neglected file the first compact can be dramatic; I have watched files shed more than half their size in one run.
Two honest caveats. First, the operation builds a complete new copy before replacing the old one, so it needs free disk space roughly equal to the size of the database. On a nearly full drive, the rescue tool itself can fail to run. Second, the gains shrink every time. Each compact removes the slack, and what remains afterwards is real data plus real attachments, which only grow.
Compact and Repair reclaims space that deleted records and temporary objects still occupy, but it does not raise the 2GB limit and its returns diminish with each run. A database that needs compacting weekly to stay under the ceiling has outgrown the file format, not the maintenance schedule.
That is the honest framing: compact and repair buys months, not years. If you are already compacting on a schedule to stay alive, the useful next step is a number, not another compact. The free 24-hour Migration Blueprint maps what is actually in your database and tells you what each way out would cost before you commit to any of them.
The four ways out
1. Move attachments out of the database
The fastest win. Store the documents in a folder (or SharePoint, or any file store), keep only the path in the database, and the file often halves overnight. It takes a few days of work with some VBA to export the existing attachments and repoint the forms. What it does not fix: the data itself keeps growing, and every other Access limitation stays exactly where it was. If embedded files were most of your problem, this buys years; if they were not, it buys little.
2. Archive historic records to a second back end
Move closed years into a separate archive .accdb. Each file gets its own 2GB, so this is the split-file nuance used deliberately. It typically buys about a year per archive round for a steadily growing database, and it creates a reporting problem in exchange: any query that spans live and historic data now has to reach across two files, and someone has to remember to run the next archive before the ceiling comes back.
3. Move the back end to SQL Server or MySQL
Upsizing the tables to a proper database server removes the ceiling on data outright (SQL Server and MySQL are not 2GB-limited) while keeping your Access forms, queries and VBA as the front end. This is the well-trodden middle path and considerably cheaper than a rebuild. What it leaves behind is the application tier: a desktop-only front end (itself still a 2GB file, though front ends rarely threaten it), Access installed and licensed on every machine, and the same desktop dependency for remote and multi-site work.
4. Rebuild as a web application
The full exit. It is also my livelihood, so read this section knowing that. Forms, queries, VBA and reports become a browser-based application on a database with no 2GB ceiling, no per-machine Office licence and proper multi-user handling. It is the most expensive way out and the only one that is a genuine project: weeks, not a weekend. It is also the only one that ends this cycle rather than extending it. I have handled exactly this scenario before: one of the case studies on my homepage is a client billing database near the 2GB limit, crashing weekly, rebuilt as a cloud billing system with an audit trail, used from three offices. Month-end invoicing now runs in one afternoon.
| Way out | Effort | What it fixes | What it leaves behind | How long it buys |
|---|---|---|---|---|
| Move attachments out | Days | File bloat from embedded documents | Data growth; every other Access limit | Years, if attachments were the problem |
| Archive to a second back end | Days, then recurring | Headroom in the live file | Cross-file reporting; a recurring chore | Roughly a year per round |
| SQL Server / MySQL back end | Weeks, with care | The data ceiling, concurrency, backups | Desktop-only front end; Access on every machine | Indefinitely, for the data tier |
| Web application rebuild | The largest; a real project | Ceiling, licences, multi-user, remote access | The old system, once you cut over | Indefinitely |
How to tell which one you need
Three checks, ten minutes, no tools beyond Access and Explorer.
Check the split. Open the Navigation Pane: tables marked with an arrow icon are linked from another file, which means you are split and it is the back end's size that matters. Everything in one file? Splitting is step zero whatever else you do.
Check the attachment volume. Look for Attachment and OLE Object fields in your largest tables. If they exist, compare the file size with a rough estimate of your real data (records × a generous few KB each). A wide gap says way out 1 will pay off immediately.
Check the growth rate. Compact, note the file size, and note it again a month later. Dividing the remaining headroom by that monthly growth gives you your runway in months. It is an honest number that tells you whether you are choosing calmly this quarter or restoring backups at month-end.
Read the three answers together and the comparison table above does the rest: heavy attachments point at way out 1, a healthy front end with data pressure points at ways 2 or 3, and a short runway on a multi-user, business-critical file is the case for way out 4. Decide it now, on your schedule, rather than at the ceiling.
If the ceiling is close
Do three things in this order. Take a copy of the file and prove it opens. Run Compact and Repair for breathing room, remembering it needs free disk space about equal to the file. Then run the growth-rate arithmetic above and choose a way out on the numbers rather than in the middle of a crash. If the answer points at a rebuild, or you want the ways out priced against each other for your specific database, the Migration Blueprint below comes back within 24 hours with the scope, the timeline and an exact fixed quote, free, without a call.