2
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
3
<!--All rights reserved.-->
4
<!--See the file LICENSE for redistribution information.-->
7
<title>Berkeley DB Reference Guide: Database limits</title>
8
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
9
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
12
<a name="2"><!--meow--></a>
13
<table width="100%"><tr valign=top>
14
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></h3></td>
15
<td align=right><a href="../../ref/am_misc/stability.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/diskspace.html"><img src="../../images/next.gif" alt="Next"></a>
18
<h1 align=center>Database limits</h1>
19
<p>The largest database file that Berkeley DB can handle depends on the page size
20
selected by the application. Berkeley DB stores database file page numbers as
21
unsigned 32-bit numbers and database file page sizes as unsigned 16-bit
22
numbers. Using the maximum database page size of 65536, this results in
23
a maximum database file size of 2<sup>48</sup> (256 terabytes). The
24
minimum database page size is 512 bytes, which results in a minimum
25
maximum database size of 2<sup>41</sup> (2 terabytes).
26
<p>The largest database file Berkeley DB can support is potentially further limited
27
if the host system does not have filesystem support for files larger than
28
2<sup>32</sup>, including the ability to seek to absolute offsets within
30
<p>The largest key or data item that Berkeley DB can support is largely limited
31
by available memory. Specifically, while key and data byte strings may
32
be of essentially unlimited length, any one of them must fit into
33
available memory so that it can be returned to the application. As some
34
of the Berkeley DB interfaces return both key and data items to the application,
35
those interfaces will require that any key/data pair fit simultaneously
36
into memory. Further, as the access methods may need to compare key and
37
data items with other key and data items, it may be a requirement that
38
any two key or two data items fit into available memory. Finally, when
39
writing applications supporting transactions, it may be necessary to have
40
an additional copy of any data item in memory for logging purposes.
41
<p>The maximum Btree depth is 255.
42
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/am_misc/stability.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/diskspace.html"><img src="../../images/next.gif" alt="Next"></a>
44
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>