Together with the MicroKernel Database Engine it uses ISAM, Indexed Sequential Access Method, as its underlying storage mechanism.
However, the file structure itself is largely built around smaller units of data, called "pages" in Btrieve.
The API likewise remained backwards compatible, with only one feature (split files to separate media) being dropped.
They separated the core database operations (like update, write and delete records) from the Btrieve and Scalable SQL modules.
Because the record primitives have been separated from these methods, both applications can use the MKDE to access the same data file.
The Micro-Kernel Database Engine is unrelated to microkernel operating system kernels.
The Btrieve file format consists entirely of pages, which is the data that moves between memory and storage media when the engine performs an I/O operation.
Since version 8 you have to calculate the page size by taking the 32-bit field at offset 0x2A and multiply with 256.
Like the FCRs, PATs always occur in pairs, with the currently valid copy indicated by having a higher usage count.
The first pair of PATs immediately follow the first two FCRs and takes up physical pages 2 and 3.
Each PAT has a fixed number of pointers to logical pages, with each entry that is empty having a value of zero.
The amount of logical records that can be stored in the PAT is determined by its page size.
In common usage, this is called alphabetisation, though collation is not limited to ordering letters of the alphabet.
A linked list approach would be able to allow for this fragmentation, but the Btrieve engine would have a hard time reading through sequential records.
Therefore, starting with version 6.1, a table is used in the file that stores pointers to each of the pages that make up the data record.
Btrieve uses a b-tree format to store record indexes on particular table columns.
The drawback of a btree is that data must be constantly balanced when it is inserted into the tree, therefore Btrieve only stores the record index as btree to reduce the amount of time it takes to insert and update records.
A separate b-tree is kept for each index in the system, and the root node information is kept in the FCR.
MEFS allows different clients running under different engines to access the database.