There are no simple answers to this question, but let me provide a few
observations.

The 64-bit file i/o change doesn't make a whole lot of difference to
maximum table size. It relates purely to file sizes. Tables are
logically structures within the engine and are separate from the
underlying file system.

Firebird can theoretically store 64K files in a database, each file
being up to the theoretical maximum of the underlying filesystem. If
ReiserFS was used files up to 1 Exabyte could be stored. Except that
either ReiserFS or the Linux kernel has a file system limit of just 16Tb
for all files. That limit will change, but it kind of blows away the
claims of most database products.

The theoretical maximum size of a Firebird table is 2^32 rows with a
limit of 64K per row (excluding blobs). This seems to work out at around
274,877,906,944 Kb or around 274 Tb for a single table if my arithmetic
isn't totally screwed up.

In general I'd say that practical problems prevent us from getting
anywhere near these limits. I'd want to be sure that a daily backup and
restore process might actually complete before the next one starts. That
might be a bit of a challenge with a 1 Tb database, even though the size
is well within the theoretical limits.


Paul
--

Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase