<snip>
Firebird seems like the perfect fit.My "jumping in" question is, which
architecture will fit our requirements?
</snip>

Hi Mike,

On thing you may not (yet) know that will make this decision a lot
easier is that the Firebird architectures are completely
interchangable. You can develop in house using Superserver, install it
using classic, or put it on a USB key using embedded without any
change to your client code.

If you realise later on that another architecture would be a better
fit, then simply uninstall/reinstall using other architecture.

There are actually only two architectures

Superserver (SS) and Classic (CS). SS runs as a single process. Each
connection shares this same process which uses different threads.
Caches are shared between connections. CS runs a separate process for
each connection. Resource-wise, CS handles multiple processors much
better, but new connections are less expensive on SS.

http://www.firebirdsql.org/manual/qsg15-classic-or-super.html

<snip>
We distribute the app stand-alone. I can't assume my users will have
anything on their systems, driver-wise.In house, we have a huge Oracle
DB. That's where I get my input. My job is to publish a subset of that
data to my users without giving away any proprietary information.From
my reading so far, it sounds like I want to use the "embedded"
architecture to essentially include Firebird in my app.
</snip>

Embedded is Superserver without the TCP request handling stuff. It is
basically the engine has been compiled into a single dll, which also
works the same way as fbclient.dll. As such, it does not require you
to install a service (not that installing FB is a hard task), it seems
like a nice fit though to your problem. There are some security (or
lack thereof) implications for the embedded model in particular, but
these are spelled out in the release notes and readme files. I have
not been sucessful in getting embedded to work under a terminal
services environment but it works great in other environments.

Adam