That is a start.

Certainly I would have no concerns with the size of the database, the
whole thing would probably fit into memory, you are not going to run
into the limitations that can be a problem for a large database. You
have not yet told us your architecture, but I will tell you right now
that client server will not cut it.

You will need to use a proper n-tier application with some sort of
connection pooling. What language are you planning on using?

Firebird has a connection limit of somewhere around 1000 simultaneous
connections. Being a contact database, you would not need the
connections open for very long to do the work. From what you have
described, there is only a single query returning a few fields. If
this is the case, you will want to spend time designing appropriate
indices to make that query fly. Firebird does not contain any
internal implementation of a full text search, so you will need to
build your own using triggers if required. Also, Firebird 1.5 can not
use an index on an expression (2.0 beta can), so you can't use where
Upper(Name)=Upper(?) and have it use an index.

You will need to decide on the Firebird type you want to install.
There are three, Classic, Superserver and Embedded. It is really only
two, Embedded is just a cut down Superserver inside a dll and can
only be accessed by a single process.

In the scenario described, I would be far more concerned over
managing the release of 10000 applications, and the network bandwidth
required to send all that data. Perhaps something web based would be
a better model. Anyway, once you have more of an idea over the
delivery model and expected connection counts, you will get a better
idea of system requirements.

I would start by reading this
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ss_vs_classic

I would think that in this case the shared cache offered by
Superserver / embedded would be more useful than the ability to make
use of multiple CPUs offered by classic.

In fact, if you have a data abstraction layer sitting inside a
service, you could use embedded which skips the TCP layer (the data
abstraction layer is the process the embedded dll would be loaded
into), which IMO would be a lot faster.

<snip>

Sorry I did not give much information. Firebird will be running 1
database consisting of 6 small tables. The most records any table
will have is 10,000. The application is essentially a contacts
database with no blob fields. The client application could be
installed on as many as 10,000 desktops, but initially less than 500.
I have no idea what the average or peak connection count will be at
this time. Speed is the key for the app. A query will be done on one
field and return 4-6 fields.

If you need more info, let me know. Thanks for the reply so far.

</snip>