Almost every long-running FoxPro application eventually meets the same hard ceiling: a single table cannot grow past 2 gigabytes. It is not a setting you can raise or a license you can buy. It is a fixed limit of the DBF file format, and the closer a busy table gets to it, the more fragile the whole system becomes.
If your application has been collecting data for a decade or more, this is one of the most common reasons a "stable" system suddenly is not.
Where the 2 GB limit comes from
Per Microsoft's own Visual FoxPro system-capacity reference, a single .dbf table is limited to 2 GB, and each .fpt memo file that holds your notes, descriptions, and large text fields carries the same separate 2 GB cap. You can browse the primary-source docs on Microsoft's Visual FoxPro documentation. The limit is structural, baked into how the file format addresses records, which is why no configuration change lifts it.
What actually breaks as you approach it
The failure is rarely a clean "file full" message. It shows up as corruption and instability well before the theoretical ceiling:
- Sudden corruption. A write that pushes a table or its memo file over the edge can damage the file, taking the table offline mid-day.
- Memo bloat surprises. Teams watch the
.dbfand forget the.fpt. A table with heavy memo fields often hits the wall on the memo file first. - Index and reindex failures. Operations that need temporary space start failing as headroom disappears.
- Slow, then stuck. Performance degrades as the file grows, and the eventual stop feels like it came out of nowhere.
Watch the memo file, not just the table. Two files share the ceiling: the .dbf and its .fpt. A modestly sized table with large memo content can hit 2 GB on the memo side while the table itself looks fine.
The workarounds, and why they are borrowed time
There are ways to keep going: archive old rows into history tables, split one large table into several, or prune memo content. Each buys time, and each adds complexity and new failure points to a system that is already hard to maintain. You are now engineering around the tool instead of with it. That is usually the real signal.
Hitting the wall is a symptom, not the disease
The 2 GB limit is not the problem. It is the messenger. It is telling you the application has outgrown the DBF file format it was built on. A modern database engine such as PostgreSQL or SQL Server does not have this ceiling in any practical sense, and it brings real concurrency, integrity, and backup guarantees that DBF files never offered.
The good news is that moving the data is the lowest-risk part of a modernization, and it can happen first, on its own. Your FoxPro application can keep running against the migrated data while you plan the rest. Our DBF-to-PostgreSQL guide covers the type mapping, encoding, and validation involved, and the data-migration service is built to do exactly this as a first phase.
Bottom line: if a busy table or its memo file is anywhere near 2 GB, do not treat it as a housekeeping chore. Treat it as your application telling you it needs a real database underneath it, and start with the data.