Everything Database Larger Than 2GB: How to Fix It

An Everything database larger than 2GB is not automatically corrupt, but it deserves investigation. A very large Everything.db can result from indexing an unusually large number of files, enabling optional properties, adding overlapping folder indexes, indexing network shares, or retaining a scope that is broader than you need. It can also become a practical problem when the 32-bit build of Everything runs short of address space, the database drive lacks free space, or startup and rebuild operations cannot complete.

The safest approach is to confirm that database size is the real symptom, inspect the indexed scope, and reduce unnecessary data before forcing a rebuild. Do not begin by deleting Everything.db, disabling security software, or changing multiple unrelated settings. Each section below explains what to check, what a successful fix looks like, and when to stop troubleshooting.

1. Confirm the Symptom With a Small Safe Test

First, distinguish a large database from a different search problem. Everything is a filename search application from voidtools. It maintains its own database and is separate from the Windows Search index used by File Explorer, the Start menu, and some Microsoft applications. Rebuilding Windows Search will not normally reduce Everything.db or repair an Everything index.

1.1 Locate and measure Everything.db

Exit Everything cleanly before measuring or copying its database. Depending on the installation and settings, Everything.db may be stored with the application, under the current user's application data, or in a custom location. Portable users should check the folder containing the executable and the configuration used by that specific instance.

Record the following before changing anything:

• The full path to Everything.db
• Its current size and last-modified time
• The free space available on that drive
• Whether Everything is running as a 32-bit or 64-bit process
• The approximate number of indexed objects shown by Everything
• Whether the file grows after each restart or only after a rebuild

A database slightly above 2GB can be legitimate for a very large environment. The stronger warning signs are failed startup, repeated rebuilds, missing results, memory allocation errors, a database that grows unexpectedly, or a last-modified time that never advances.

1.2 Run a controlled filename search

Create a uniquely named empty file in a local folder that should already be indexed, such as everything-db-test-2025.txt. Search for the complete filename in Everything without filters, regular expressions, or restrictive search options.

If the file appears promptly, the active index is updating at least for that location. If it does not appear, check the status bar and clear the search field, filters, and result omissions before assuming that database size is responsible. A missing test file often points to scope, exclusions, filter state, or update monitoring rather than a 2GB limit.

Success at this stage means you know the database path, architecture, indexed item count, free-space condition, and whether a new local file enters the index. Stop changing settings if searches work, startup is stable, and the database size matches a genuinely large indexed scope. Size alone does not require repair.

2. Check the Everything Settings That Directly Increase Database Size

The most effective Everything database larger than 2GB fix is usually to remove data that does not need to be indexed. Review settings methodically and take notes so that you can reverse an incorrect change.

2.1 Confirm that you are using the x64 build

On 64-bit Windows, use the x64 build of Everything when maintaining a very large database. A 64-bit process has substantially more address space available than a 32-bit process, which matters when Everything loads, updates, sorts, or rebuilds a large index. The database file being larger than 2GB does not by itself prove that a fixed file-size limit has been reached, but a 32-bit process can encounter practical memory constraints sooner.

Open the About information or inspect the process in Task Manager to identify the running architecture. If you switch builds, preserve a backup of your configuration and confirm that you launch the intended executable afterward. Portable users should be especially careful because an old shortcut may continue opening a separate 32-bit copy.

Success means the active Everything process is 64-bit, opens the existing index reliably, and can complete an index rebuild without memory-related failure. If these conditions are met, do not keep switching versions in search of a smaller file. Architecture improves capacity, but it does not remove unnecessary indexed content.

2.2 Review optional indexed properties

Everything's basic filename index is compact relative to indexing additional metadata. Optional properties can increase database size and memory use because more information must be stored for each indexed object. Depending on your configuration, these may include values such as file size, dates, attributes, or other properties used for sorting and searching.

Open the Indexes-related Options pages and identify properties you intentionally enabled. Keep a property only when you regularly search, sort, or filter by it and need that operation to be fast. Removing a displayed column is not necessarily the same as disabling its indexing, so inspect the property or index setting itself.

Disable one unnecessary category at a time. A change may not produce its full size reduction until the database is rebuilt. Success means the rebuilt database is smaller while the searches and sorts you actually use still work. Stop removing properties once the size is manageable and your normal workflow remains intact.

2.3 Remove duplicate or unnecessary folder indexes

Folder indexing is useful for locations that Everything cannot monitor through its normal local NTFS indexing method, including many network shares and non-NTFS file systems. It can also create unnecessary volume when the same content is included through more than one index path.

Inspect every configured folder index and ask:

• Is the same directory covered by both a local volume index and a folder index?
• Do two share paths point to the same NAS directory?
• Is a parent folder indexed along with several child folders?
• Are backup snapshots, recycle folders, caches, or version stores included?
• Is an old server or disconnected share still configured?
• Does a portable profile contain folder indexes copied from another computer?

Remove only entries you recognize as redundant or unnecessary. If a folder index represents the only way Everything sees a required NAS share, removing it will remove those results. Success means the item count falls by roughly the expected amount after rebuilding, without losing required locations.

2.4 Inspect exclusions and result omissions

Exclusions can reduce indexed scope, while result omissions can merely hide matches from view. This distinction matters when Everything results are missing. A hidden result does not prove the file was never indexed, and an omission rule may make a healthy database appear incomplete.

Review exclusion settings for volumes, folders, files, and patterns. Also clear active filters and any commands or options that omit results. Test a known full path and a unique filename. If the item appears only after clearing an omission or filter, the database was not the cause.

Success means required files appear with a blank search filter and unwanted locations are excluded at the correct stage. Once the behavior is explained, stop changing index settings.

2.5 Check command-line and server options

Shortcuts, scheduled tasks, portable launchers, and management scripts can pass command-line options that select a different configuration, database, instance, or startup behavior. Everything may therefore open a database other than the one you inspected. Check the shortcut target and any script used to launch the application.

If you use an Everything server or client arrangement, verify which machine owns the index and which instance is answering the query. A client-side result problem should not automatically be treated as local database corruption. Keep server access restricted to trusted networks and use appropriate authentication and firewall controls. Do not expose a search service directly to the public internet as a troubleshooting shortcut.

Success means one known executable, profile, database path, and instance account for the test. If the expected database loads and results return, avoid changing server settings further.

3. Check Windows Storage, Permissions, Services, and Network Context

Everything can have correct index settings but still fail to save, update, or rebuild a large database because Windows presents a different storage or account context.

3.1 Verify database location and free space

A rebuild can require more working space than the final database occupies. Confirm that the database volume has ample free space, is writable, and is not a read-only portable medium. Avoid placing an actively updated database in a cloud-synchronized folder unless you understand how the synchronization tool handles frequently changed database files.

Check the database folder's permissions using the same Windows account that launches Everything. If the application runs elevated, through a service, or as another user, the relevant account may differ from your interactive account.

Success means Everything can update the database timestamp, close normally, restart, and retain new results. If all four checks pass, storage permissions are unlikely to be the cause.

3.2 Understand NTFS volumes and folder indexes

Everything can index local NTFS volumes efficiently by reading file-system metadata and monitoring changes. Network shares do not present themselves to a local application in the same way, even when the remote server uses NTFS. NAS devices, mapped drives, and non-NTFS storage are commonly handled through folder indexing or a remote Everything service.

A mapped drive is also account-specific. A drive letter visible in your desktop session may not exist for an elevated process, service account, or scheduled task. When a mapped drive disappears under another account, use a properly authorized UNC path where supported or arrange the mapping within the account that runs the process.

Success means each required location appears once, can be read by the active account, and updates using an appropriate indexing method. If local files update but NAS files do not, focus on the folder index schedule, credentials, and network availability rather than rebuilding every local NTFS index.

3.3 Check the Everything service state

The Everything service can provide access needed for local NTFS indexing without requiring the user interface to run permanently as administrator. Check that the intended service is installed, running, and associated with the Everything instance you use. Repeatedly launching different elevated and non-elevated copies can create confusing profile and database behavior.

Restarting a stopped service is reasonable, but first record its state and any Windows error. Do not repeatedly reinstall it before checking logs and account context. Success means the service remains running, local NTFS volumes are available to Everything, and new files enter the index.

3.4 Evaluate antivirus and controlled-folder protections safely

Security software may inspect a large database during writes or restrict access to protected folders. Check the security product's history, Windows Event Viewer, and Controlled Folder Access notifications for a specific block involving Everything or its database path.

Do not disable antivirus permanently. If policy permits, use a narrow, temporary diagnostic test or a carefully scoped exclusion for the trusted executable or database location, then reassess. In managed environments, ask the security administrator to review the event rather than bypassing controls.

Success means a documented block is resolved and database saves complete normally. If there is no security event and permissions are valid, restore normal protection and investigate elsewhere.

4. Rebuild and Diagnose the Index in a Controlled Order

After reducing indexed scope or optional properties, rebuild the database so that removed data is no longer retained. Rebuilding before correcting the configuration often recreates the same oversized database.

4.1 Use the status bar and Options pages first

The status bar can reveal result counts, indexing activity, or whether a restrictive filter is active. Compare the total indexed object count before and after each scope change. In Options, review NTFS volumes, folder indexes, exclusions, indexed properties, database location, service settings, and update schedules.

Write down the original value of every setting you change. This turns troubleshooting into a controlled comparison instead of guesswork.

4.2 Run Force Rebuild after reducing scope

Once you have removed duplicate folders, unnecessary volumes, or optional properties, use Everything's Force Rebuild function. Leave the application open long enough to finish, particularly when scanning large folder indexes or network shares. Avoid interrupting the process unless it is clearly stalled and diagnostics show no progress.

After completion, check:

• The indexed item count
• The new Everything.db size
• The database last-modified time
• Searches for known local and network files
• Whether a newly created test file appears
• Whether Everything restarts without rebuilding again

Success means the new database reflects the reduced scope, remains stable across restart, and contains all required results. At that point, stop changing settings even if the file is still large. A large but stable database can be correct for a large collection.

4.3 Use debug logs and the Index Journal when needed

If Everything search is not working or the index is not updating, enable diagnostic logging using the application's supported debug facilities. Reproduce one specific failure, such as creating a test file or refreshing a folder index, then inspect the relevant messages. Avoid collecting an enormous log without a test plan.

The Index Journal can help establish whether an item was added, changed, or removed from the active index. Search syntax tests can also separate index failure from query failure. Start with an exact filename, no filter, no regex mode, and no custom macros. Then add one search operator at a time.

Success means you can identify the stage at which the item disappears: file access, index inclusion, update monitoring, query interpretation, or result omission. Once the stage is known, change only the related setting.

5. Run a Clean Temporary Test Before Changing Many Settings

If the existing profile is complex, create a temporary clean test rather than deleting the working database. Back up the current configuration and note the database location. Launch a separate trusted copy or instance with a new configuration and database path, ensuring it cannot overwrite the production profile.

For the temporary test, index one small local NTFS volume or one small test folder. Do not add NAS shares, optional properties, servers, exclusions, or custom filters initially. Create several uniquely named files and confirm that they appear, change, and disappear as expected.

Then add one production feature at a time:

1. Add the required local volumes
2. Add necessary folder indexes individually
3. Add exclusions for clearly unwanted trees
4. Enable only required optional properties
5. Test the normal startup method and service context
6. Test remote or server access last

If the clean profile stays small and responsive, the original configuration probably contains excessive scope, duplicated indexes, or a setting interaction. If the clean profile fails with a small local test, investigate architecture, storage permissions, service state, or security controls before touching production data.

Success means the minimal profile works and the failure reappears only after one identifiable feature is added. Stop at that point and correct that feature rather than continuing to add variables.

6. Quick Fix Checklist

• Confirm the actual Everything.db path, size, timestamp, and drive free space
• Use the x64 build of Everything on 64-bit Windows for very large indexes
• Check that an old shortcut is not launching a separate portable or 32-bit instance
• Review optional indexed properties and disable those you do not need
• Remove duplicate folder indexes, overlapping paths, and obsolete network shares
• Exclude backup snapshots, caches, or other large trees only when they are not needed
• Clear filters, search modes, and result omissions before diagnosing missing results
• Verify the Everything service is running and associated with the intended instance
• Confirm the active account can access mapped drives, UNC shares, and the database folder
• Check security logs for a specific block without permanently disabling protection
• Force Rebuild only after reducing indexed scope or optional properties
• Validate the final item count, database size, restart behavior, and known test files

7. Frequently Asked Questions

7.1 Is an Everything database larger than 2GB corrupt?

No. File size alone does not establish corruption. A database can legitimately become very large when it represents many files, extra properties, multiple folder indexes, or large network collections. Suspect a problem when Everything cannot load or save the database, rebuilds repeatedly, reports errors, or produces inconsistent results.

7.2 Does the x64 version support large Everything databases?

The x64 build is the appropriate choice for very large databases on 64-bit Windows because it can use a much larger process address space than a 32-bit build. This reduces architecture-related memory pressure, but it does not make unnecessary indexing free. You should still remove duplicate scope and unused properties.

7.3 Why did enabling properties make Everything.db much larger?

Indexed properties store additional information for many or all indexed objects. Even a modest amount of metadata per item becomes significant across millions of files. Disable properties you do not search or sort by, then rebuild the index to measure the full reduction.

7.4 Why are files from my NAS missing?

A NAS share is not indexed like a local NTFS volume. Check the configured folder index or remote Everything server, network credentials, account context, scan schedule, exclusions, and share availability. Also verify that an elevated process or service can see the same path as your desktop account.

7.5 Should I delete Everything.db and start over?

Not as the first step. First identify the database location, preserve configuration, verify free space, reduce unnecessary indexes, and use Force Rebuild. A manual deletion can erase useful diagnostic evidence and may simply recreate the same oversized database if the configuration remains unchanged.

7.6 What does a successful fix look like?

A successful fix produces a database that completes its rebuild, saves to disk, opens normally after restart, updates when test files change, and returns required local and network results. The database does not have to fall below an arbitrary size if the indexed collection genuinely requires it. Stability, correct scope, and predictable updates are the practical goals.