I understand (too well!) that "scalability" is a fuzzy concept. But,
each of the factors that are used to define the concept in different
areas can be expressed clearly and distinctly. It should be possible to
develop some guidelines as starting points for scaling hardware and
configurations for Firebird based on the application, the user base, and
the environment.

Is there a already published configuration guideline that addresses
Firebird hardware and software scaling for different purposes? I expect
that when I finally get Helen's book, it will have some of this
information.

For example, I am mostly concerned with large real-time systems (TB)
with a large and busy concurrent user base (1,000 to 8,000 users).
However, I also work with standalone desktop apps and even occasionally
with handheld applications. What I like about Firebird is that it is
conceptually possible to run the same datastore on all of my platforms.

It is easy to find information on the mailing list and Google for
configurations from 1 to 100 user connections, or small web-server
applications with connection pools of up to 100 concurrent connections.
Third party products such as C-JDBC allow clustering for databases that
run primarily "read" operations, such as web sites, but cannot compete
with a larger centralized store for enterprise scale real-time
monitoring applications.

The down-scaled applications (hand held devices) and the up-scaled
applications (centralized real-time monitoring, recording and management
of all of a fortune 500 company's fixed and mobile resources) are
tougher to find information on.

If there is not already such a document, I would like to propose that we
make one that addresses hardware and software configuration for scales
something like these:

1. mini - embedded hand held device and PLC applications

2. desktop - embedded desktop applications

3. tiny - 1 to 10 clients talking to a shared server, or a web
application that requires 1 to 10 pooled connections

4. small - 10 to 100 clients talking to a shared server, or a web
application that requires 1 to 100 pooled connections

5. medium - 100 to 1000 clients talking to a shared server, or a web
application that requires 1 to 1000 pooled connections

6. enterprise - 1000 and up clients talking to a shared server, or a web
application that requires 1000 and up pooled connections

Allowance must be made in the guidelines for the type of work being
performed on the server, and clustering options should also be
addressed.

For example, a web application is typically read intensive by has low
write to read ratio, so clustering several smaller machines with a third
party product such as C-JDBC may be a better choice from both a cost and
performance perspective than a single large box.

A counter example is a large centralized real-time asset monitoring and
management tool for a fortune 500 company, where nearly 50% of the
transactions involve writes. In this case, clustering actually harms
performance, and a much larger box is desirable.

Related to scalability and clustering, I read that Firebird's
predecessor was actually built to run on a VAX cluster. Is that code
still in place, will it run on modern Windows and linux systems, and
does it provide any benefit in today's world?