DB File

What are DB files and how to open them

Are you having problems opening a DB file or are you simply curious about its contents? We're here to explain the properties of these files and provide you with software that can open or handle your DB files.

What is a DB file?

DB files have multiple uses, and Database is one of them. Read more about the other uses further down the page.

Database File

Files with the .db extension typically contain generic database files. These files store data in tables, and various database applications create them.

The .db file extension is also associated with the Thumbnail database files that are created within the Windows operating system. The Oracle database is another application that is commonly used to create files with the .db extension.

Because a wide variety of applications create DB files, the format of files within a file containing a .db extension may vary from one file to the next. Use the File.org File Analyzer to find out exactly what type of DB file you have.

How to open DB files

Important: Different programs may use files with the DB file extension for different purposes, so unless you are sure which format your DB file is, you may need to try a few different programs.

While we have not verified the apps ourselves yet, our users have suggested ten different DB openers which you will find listed below.

Last updated: October 22, 2026

All known file formats using extension .DB

While Database File is a popular type of DB-file, we know of 25 different uses of the .DB file extension. Different software may use files with the same extension for different types of data.

Apple Spotlight Store Data Base

Apple Spotlight store database files hold the internal index and metadata that Apple's Spotlight service builds for quickly finding files and file contents on MacOS and iOS. These databases are written by the Spotlight system and are part of its Store-V2 directory (or variants) alongside other map and metadata files.

These store database files are not ordinary SQL or SQLite databases; they use a proprietary structured format designed for Spotlight's indexing. Contents include a fixed-size header, maps locating metadata and data blocks, property tables describing metadata attribute types and values, and data records for individual filesystem entries including creation and modification times, file hierarchy identifiers, and attribute values. Data is stored little-endian. Some blocks (property tables) are compressed using zlib/DEFLATE or LZ4.

The header begins with the ASCII signature "8tsd" at offset 0.

Berkeley DB

Berkeley DB is a software library that creates and manages high-performance, embedded database files using B-tree, Hash, Recno, Queue, or Heap data structures. It is written in C (with APIs for other languages) and designed to be linked into applications rather than run as a separate server. Berkeley DB files are used when an application needs fast, scalable storage with built-in transactions, logging, locking, or recovery features.

The library produces binary database files that store both keys and associated data. Applications call routines such as DB_ENV->open() and DB->open() (or equivalent) to create or open these database files. Utilities provided with Berkeley DB include db_dump to export a database to a portable text form and db_load to recreate the binary file from that dump. Berkeley DB supports moving database files between machines of different endianness only in certain formats.

Technical internal structures include metadata pages that record layout, version, page size, and uniqueness of records, followed by pages of data entries. A specific byte signature can identify a hash-type Berkeley DB database: the 4-byte magic value 0x00061561 stored at offset 0, which helps the file utility on Unix identify that it is a Berkeley DB file.

Checkup Data Base

Checkup Data Base is a file format produced by a DOS utility used to record information about file integrity. It serves as a reference database against which the utility checks whether files have been altered, missing or corrupted. These records allow comparisons over time to find unexpected changes in file contents or structure.

This format is written and read by the "Checkup" program in DOS. The program creates this database to remember checksums or signatures of files and later verifies current files against those signatures to detect modifications. It is not a general-purpose reader for regular database users - it is specifically tied to the Checkup tool's routines for integrity checking.

Files in this format begin with ASCII headers and fixed tags that identify them to the Checkup utility. A signature appears at offset 34 reading "CHECKUPDatabase,DONOTCHANGETHISFILE!#". Additional identifying strings such as "DO NOT CHANGE THIS FILE" and "CHECKUP DATABASE" are found later in the file. Specific byte signatures include 0x2320 at offset 0 and 0x20 at offset 31.

DataBase Professional Database File

We know that one DB format is DataBase Professional Database File. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

DIGIBooster Audio File

We know that one DB format is DIGIBooster Audio File. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Everything Data Base

Everything Data Base is the format used by Everything (by Voidtools), a Windows search tool, to store its file indexing database. The database holds records of every file and folder across fixed local NTFS (or ReFS) volumes. It is built when Everything is first run and updated in near-real-time as file system changes occur. The primary purpose is to allow instantaneous filename searches without needing to traverse disks each time.

Everything Data Base files are created and maintained by Everything (by Voidtools) itself. Users customize index settings through Everything's Options → Indexes, which determine which volumes are scanned and what additional file metadata (size, date modified, attributes, etc.) is stored in the database. The database file is named Everything.db and is typically located in the user's local application data folder (%LOCALAPPDATA%\Everything) unless set otherwise.

Files in this format allow the Everything program to respond to filename queries near-instantaneously by looking up paths and file names within the database rather than scanning storage every time. When files or directories change, Everything updates its database so search results reflect current filesystem state.

The file begins with a byte signature of ASCII "ESDb" (hex values 45 53 44 62) at offset zero, which identifies it as the Everything file index.

H2 Database

H2 Database files hold all data, indexes, and transaction history for an H2 database engine when using its MVStore storage format. These are disk-based, transactional relational database files produced by H2 written in Java, storing tables, schemas, indexes, and persistent state in one or more chunks so that every committed change becomes part of a new version.

When H2 creates a new persistent database, it writes its storage in a single file that uses MVStore. This file is updated over time by appending "chunks" corresponding to versions, rather than modifying in place. Two redundant headers are stored at the start, each one block-aligned (commonly 4096 bytes), so that if one header is damaged the other can be used. The file keeps track of version numbers, creation timestamp, format number, and checksum to ensure consistency. When applications open such a database file, H2 uses the newer valid header, locates the latest chunk, reads B-tree pages from it, and reconstructs data structures as of that version.

Internally, the format's file header begins with ASCII text "H:2,block:…," including key-value pairs such as blockSize, chunk, created, format, version and fletcher (a Fletcher-32 checksum) to verify integrity. The layout is: two file headers (each one block), followed by one or more chunks; each chunk includes a header, a series of page records, and a footer. Metadata keywords include H, block, blockSize, chunk, version, fletcher.

H2 DB

H2 DB is the file format used by the H2 Database Engine when it uses its PageStore storage system. It serves as the main persistent storage file for an H2 database instance: storing the committed transaction log, all table data, and index data. It is created by H2 when a database is configured (or when using PageStore explicitly), and read by H2 when the database is opened later.

H2 is a relational database written in Java. It supports both in-memory and on-disk storage. When on-disk storage is used under the PageStore engine rather than the default MVStore engine, the main database file follows this format. Data in that file includes row contents for tables, B-tree structures for indexes, and transactions needed to recover the database after unexpected shutdown.

Files of this type are named with the database's logical name followed by the suffix ".h2.db", for example MyData.h2.db. The H2 engine recognizes that suffix as the standard PageStore database file. Other supporting files also use related suffixes: for locking (".lock.db"), for tracing activity (".trace.db"), for temporary blobs (".temp.db"), and for large objects (".lob.db").

When reading or writing such a file, H2 first checks two file headers (stored in two separate fixed blocks near the beginning of the file) that contain metadata such as format version, creation time, block size, and a checksum. After those headers, the file consists of a sequence of pages (fixed-size blocks), organized into B-trees for tables and indexes. Each time data changes and is committed, H2 writes the transaction log and updates pages and index roots in place as needed so the database can be recovered safely.

LiteDB Database File

LiteDB Database File format holds a self-contained, single-file document database produced by the LiteDB library for .NET. It stores collections of schema-less documents (in BSON format), indexes, and optional file storage within one file. The format supports querying, indexing, transactions and encryption. It is fast, lightweight and intended for applications needing an embedded embedded NoSQL database without a separate server.

Files are created by LiteDB (for example via LiteDatabase in C#) and read/modified by that same library. Data in the database are grouped into "collections" where each document is JSON-like, and indexed for fast search. LiteDB maintains internal system collections for metadata and supports storing large binary data by splitting it into chunks. Encryption using salted AES may be enabled via the connection string.

Internally, the file is organised into fixed‐size pages (4096 bytes in v4.x) each carrying one of several types such as header page, collection page, index page, data page, extend page, or empty page. The first page (header page) contains version, file size and free‐list pointers. Documents larger than a page use extend pages chained together.

Mlocate Database

Mlocate database files store a snapshot of the file system directory tree built by the program updatedb. They enable the locate command to quickly search for files by name without having to scan the whole file system each time. These binary database files are rebuilt periodically (often daily by cron) to reflect changes such as new, moved or deleted files.

The files are written by updatedb and read by locate. updatedb assembles the file list, skipping directories or file systems specified in its configuration (via variables like PRUNENAMES, PRUNEPATHS, PRUNEFS, PRUNE_BIND_MOUNTS) and records the root path, timestamps, directory contents and names so that locate can match patterns against stored file names efficiently.

Inside a mlocate database there is a fixed-header part, followed by a configuration block reflecting pruning settings, then a sequence of directory records. Each directory record begins with its time (with seconds and nanoseconds precision), padded bytes, and its full path. It is followed by file entries, each entry starting with a type byte (non-directory, subdirectory, or end-of-directory marker) plus NUL-terminated names.

Files of this type can be recognized by a magic header: the first bytes are the ASCII sequence "\0mlocate", followed by configuration parameters. Keywords like PRUNE_BIND_MOUNTS, PRUNENAMES, PRUNEPATHS, PRUNEFS and the string "MLOCATE" are embedded in the configuration block.

Neoline X-COP Data

Neoline X-COP Data files store GPS radar and camera location data used by Neoline's X-COP line of radar-detector and hybrid video devices to alert users to fixed speed-control points and radar installations. These files are published periodically by Neoline on their website so that users can download the latest "GPS base" database and install it onto their device's microSD card or USB drive for use in the GPS/radar alert features.

These data files are produced by Neoline and included with device firmware/package updates. During the installation process the device's menu offers a "Database Update" option which reads the file and installs its contents into the built-in GPS base. The file must be named in a pattern recognizable by the device (for example "X-COP9100s Baza_GPS_Neoline_20.04.18.db") so that Neoline's firmware accepts and processes it.

Files of this kind begin with the ASCII header "BRMSC" in the first five bytes (bytes at offset 0x0 through 0x4).

The extension aliases "EFM", "RD", and "VOI" are used for different types of package files (firmware, radar firmware, or voice-package) but the "Neoline X-COP Data" format specifically refers to the GPS base database content, which uses the plain ".db" extension.

Nutshell Database File

We know that one DB format is Nutshell Database File. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Palm Zire Photo Database File

We know that one DB format is Palm Zire Photo Database File. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Panasonic TV Channel Database File

Panasonic TV Channel Database File stores television channel list data extracted from certain Panasonic television sets, especially how channels are organised when exported to USB or accessed via TV firmware. It includes channel numbering, favourite lists, flags such as encrypted or hidden/skipped, and labels such as "DIGITAL+" or "TELETEXT." These files are handled by TV software that writes the channel arrangement and then used by tools to view or edit that list off-device.

The format was deciphered by the ChanSort project. It is a SQLite-based database format used by Panasonic to read and store the internal channel list (for example export files named tv.db, svl.db, or channel.db from particular Panasonic models). ChanSort edits or reorders these files so they can be imported back into the TV. Panasonics with firmware exporting SQLite DBs are the source; editing applications are secondary.

Internally the file begins with a signature "PSDB\0\0" at byte offset 0, and contains the string "SQLite format 3" at offset 126, confirming it wraps a SQLite database. Other recognizable strings include "MEDIA BROADCAST", "DIGITAL+", "CSAT", and "TELETEXT" which refer to broadcaster identifiers or channel-types.

Plocate Database

Plocate Database files store an index of file names and paths for the locate utility on Linux systems. They are produced when the updatedb component of plocate scans directories to record every file path under certain roots. These files allow locate to answer which paths exist without rescanning the entire filesystem each time.

This format is created and maintained by plocate's updatedb program. When updatedb runs (often via a systemd timer), it either creates a new database or updates an existing one, reusing unchanged directory data to speed up operation. The configuration options like PRUNEFS, PRUNENAMES, PRUNEPATHS and PRUNE_BIND_MOUNTS decide which filesystems, names, or paths are excluded from scanning.

Internal structure begins with a configuration block holding the current values of pruning and visibility settings so that the database reflects precisely what was scanned. After that come records of directories and file entries under those directories, often including modification times or other metadata to determine what's changed on subsequent updates.

Files in this format begin with ASCII signature .plocate at byte offset 0, followed by zero bytes at selected offsets (for example offset 9 and offset 41), and contain strings like PRUNE_BIND_MOUNTS, PRUNENAMES, PRUNEPATHS, PLOCATE, PRUNEFS embedded to identify pruning configuration parameters.

Raima Data Manager Database

We know that one DB format is Raima Data Manager Database. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Sybase Data Base

Sybase Data Base files store the metadata (schema, system tables, stored procedures) for a Sybase IQ database. They are generated when a database is first created, held in the Catalog Store, and play a central role in defining and managing the database structure.

These files are written by the Sybase IQ server during a CREATE DATABASE operation. They persist throughout the life of the database, enabling tools such as Interactive SQL or Sybase Control Center to query system tables and view the schema. Changes to these files occur whenever the database schema or its system-defined elements are modified.

Technically, these files consist of page-based storage (typically 4 KiB pages, though configurable) holding rows for system tables, metadata, and various control structures. They often contain readable ASCII strings such as COPYRIGHT (C), SYBASE INC., JOIN, PVAL, GDEF, and numerical sequences. Byte signatures include specific bytes at offset 0 and at offset 17.

TeXnicard Card Database

TeXnicard Card Database files store collection data used by the TeXnicard flashcard application. They are SQLite 3 databases that hold tables such as CARDS, SYSTEM_VARS, and USER_VARS, which encode a user's flashcards, app settings, and user-specific variables. The primary purpose is to let users organise, revise, and track flashcards and related metadata within TeXnicard.

These databases are produced by the TeXnicard application. They are opened and used only by TeXnicard itself or by generic SQLite tools when needed for backup, migration, or recovery. The app reads data such as the card contents, revision history stored in SYSTEM_VARS, and user preferences stored in USER_VARS to present flashcards for review and track progress.

As a distinguishing technical detail TeXnicard Card Database files begin with the ASCII-header SQLite format 3 at offset 0, identifying the file as a standard SQLite 3 database, and contain a 4-byte application id field set to 0x6A035744 (which equals decimal 1778603844) located at offset 68.

ThinManager Configuration File

ThinManager Configuration files store the entire configuration of a ThinManager server - including definitions of terminals, display clients, remote desktop servers, licenses, security settings, PXE boot information, synchronization settings, and other parameters used to manage thin clients centrally. These files are created by ThinManager when using the "Backup Configuration" function, and are meant to be restored to set up a server to the same state.

The configuration file is written and used by the ThinManager application itself. An administrator triggers its creation via ThinManager's backup tool (Manage → Backup Configuration), producing a single file that encapsulates the current board- or site-wide settings. ThinManager also supports automatic backups and manual restores using these files to replicate or replace the server configuration.

Starting in ThinManager version 11.2, this configuration file is encrypted using AES. A password is required for the encryption key when ThinManager is first run or upgraded from earlier versions. Backups saved via the backup function may prompt for a separate backup password. Transfer or restore of an encrypted configuration requires knowledge of the password used.

Technical identifier details: the file is typically named ThinManager.db (or another name ending in .db) and located in the ThinManager installation directory. It is a full configuration database rather than a simple text or INI-format file.

Twist Database File

Twist Database File holds the data for a HiSoft Twist relational database on the Amiga, used to store records with user-defined fields and to support queries, reports, and data entry via the Twist application. It encodes the structure of the database (field names, types, record count) along with the actual records written in list or record form depending on the mode prior to saving.

The file is produced and used exclusively by the Twist (also called MaxonTwist/Twist 2) program from HiSoft (later Maxon) on Amiga computers. The typical workflow: a user designs or edits a database schema (defining fields, their types, printable reports etc.), then enters data records, and saves the database file. Twist can later open the database to view, edit, run reports, or export or use with mailmerge.

Files start with the hex sequence B1 76 23 at offset zero; this sequence identifies the file as a Twist Database file rather than another use of the .DB extension.

VoidTools Everything Index File

VoidTools Everything Index File is a proprietary database used by the Everything search tool on Windows to store a list of files and folders for ultra-fast filename/path-based searching and sorting. The file is created and updated by Everything, and kept largely in RAM while running; it's saved to disk (named Everything.db by default) when the user closes Everything or changes its indexing settings. Its main purpose is to let Everything immediately show matching files as you type, using data about file names, paths, and optionally file size, dates, and attributes.

When running for the first time, Everything scans all fixed NTFS (and optionally ReFS) volumes to build this index. It then monitors file system changes (such as in the NTFS change journal) to keep its database current in real time. Certain information such as size, date modified, and attributes may be indexed by default, while others (like creation date or folder size) may be optional via settings. The database can be relocated, compressed, or rebuilt via Everything's settings, and a tool is provided to extract all filenames from Everything.db.

The file begins with a fixed header: the first four bytes are the ASCII "EZDB" (hex 45 5A 44 42) signature (or "BDZE" if byte-swapped). That is followed by a version field, flags specifying excluded file types (hidden, system), counts of folders and files, and other metadata. Sections of the file optionally store filesystem-specific information and compacted, sequentially compressed names and paths using techniques like truncation from previous strings to reduce redundant data. Bzip compression may be used on the whole db file to reduce disk size.

DB opener for Windows

We have identified one DB opener that is compatible with this specific type of DB file.

VW Comms Database

We know that one DB format is VW Comms Database. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Whatsapp Messages Database File (Symbian)

We know that one DB format is Whatsapp Messages Database File (Symbian). We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Windows Thumbnail Database File

Windows Thumbnail Database File holds cached preview small images for folders: Windows Explorer automatically creates such files in directories when thumbnails or filmstrip view is enabled. Their purpose is to speed up display of thumbnail previews of photos, videos and other media without having to regenerate them each time. These files were used primarily in Windows versions from Windows 95 OSR2 through Windows XP; starting with Windows Vista Microsoft moved to centralized thumbnail caches instead. National Archives PRONOM identifies the Windows XP version as one such format.

The file is generated by Windows Explorer using Microsoft's OLE2 Compound Document Format (also known as Compound Binary File Format). Its internal structure includes a catalog or index stream mapping original file names to thumbnail entries, and separate streams or entries containing individual thumbnails, which are stored in JPEG format, regardless of the original file format. Thumbnail sizes are typically 96×96 pixels, or proportional smaller size depending on view settings.

Windows XP thumbs database files can be detected via signatures derived by reverse‐engineering. One signature used by the PRONOM registry identifies a catalog portion beginning with a four byte sequence that seems to encode database version, followed by two bytes denoting how many thumbnails are present and data about their resolutions.

Byte signature information includes the Compound Document header signature beginning with hexadecimal D0CF11E0A1B11AE1… and parts such as a "Root Entry" stream label at a fixed offset; for example the bytes representing "R o o t E n t r y" appear at offset 1024 to identify a Root Entry stream.

Various apps that use files with this extension

These apps are known to open certain types of DB files. Remember, different programs may use DB files for different purposes, so you may need to try out a few of them to be able to open your specific file.

Help us help others

File.org helps thousands of users every day, and we would love to hear from you if you have additional information about DB file formats, example files, or compatible programs. Please use the links below or email us at submit@file.org to discuss further.