How many contacts will the Outlook database hold?

  • Thread starter amFtZXMgamFuc2Vu
  • Start date Views 1,485
Not open for further replies.

neo [mvp outlook]

You don't mention what version of Outlook you are using. So here is a quick

run down...

Outlook 97-2002 with large PST support turned on


Outlook 2003/2007 using a unicode PST

more than any mere mortal needs

Note: These numbers are per folder in Outlook.

"james jansen" <jamesjansen> wrote in message


james jansen wrote:


See that big white space? That is where you put the DETAILS of your

question for which the Subject header is merely an introduction.

So for WHICH version of Outlook are you asking?

Versions 2000 and earlier supported a maximum of 16,384 records (items

in the database which include folders, calendar events, journal entries,

e-mails, tasks, and contacts). If you select the "Allow upgrade to

large tables" option in version 2000, or earlier, the maximum goes to

65,536 items total in the message store. As of version 2002, and for

later versions that use the ANSI file format, this option is not shown.

Instead Outlook automatically upgrades to using large tables when the

total number of records exceeds 16,383.

ANSI .pst files had 32-bit headers. The later Unicode .pst files have

64-bit headers. The Unicode .pst format available in OL2003, and later,

defaults to an initial maximum filesize of 20GB but can go up to 33TB

(via registry edits). I believe the total number of records in a

Unicode .pst file is 128 million.

After more than a decade, Microsoft still refuses to publish a binary

file specification for their PST files although they do publish them for

other binary file formats. See:

where you will notice their PST format has no published specification.

There is a library available for programmers that want to directly

access the .pst files without using Outlook as a 3rd party broker to

handle managing the database. There is a link at that project page

describing the format of the records in the .pst database file. While

the ANSI format is the 32-bit format, apparently only 16 bits are

available for indexing entries (2^16 = 65,536). In Unicode format that

went to 64 bit lengths for headers, index addressing seems limited to 32

bits but 4 of them are zeroed leaving only 28 bits. While 2^28 =

268,435,456, I've heard the limit was half that (maybe they screwed up

and used a signed integer for the field type). The libpst document for

> .pst format says, "So far we have only described internal index

references where the high order 16 bits are zero. That suffices for

single descriptor blocks. But in the case of the type 0x0101 descriptor

block, we have an array of subblocks. In this case, the high order 16

bits of an internal index reference are used to select the subblock.

Each subblock starts with a 16 bit indexOffset which points to the count

and array of 16 bit integer pairs which are offsets in the current

subblock." Okay, then that makes 32 bits total (16 for the offset

within a block and 16 for identifying the block).

Maybe someone else more familiar with the header and record layout

specification for a binary tree database file format can decipher what

the libpst document says. With the ANSI .pst file, you get 65,535 items

total in the database. With the Unicode .pst file, you get 134,217,728

or maybe 268,435,456 - but it really doesn't matter because I doubt any

user, even a corporation, would generate that many records in the .pst

database file and still be able to use it due to severe slowdown in

accessing the records within it). Doable doesn't mean usable.
Not open for further replies.

Similar threads