In Process vs Client Server
Most SQL engines are implemented in a separate process known as the Database Server
process. Client applications usually communicate to the Database Server over
named pipes or TCP/IP sockets. The results of the client request are usually
transmitted through this communication channel back to the client app (which may
be on the same, or a different machine).
Embedded Database
VistaDB works as an embedded database. Our small database engine loads
within your process and communicates directly with the database file.
There are no other processes between your application and the database. This
is sometimes referred to as an embedded database (the database engine is hidden
from the user by being embedded into your application).
Pros / Cons
Of course there are pros and cons to every design. The main advantage is that
each client is just xcopy deployed, there is nothing to setup or configure on the
target machine (known as zero config). Applications
built using VistaDB require no admin rights on the target machine in order to run.
The embedded database engine lives only as long as your application is running.
Once your application exists, so does the database engine.
This also means that bugs in your application can cause crashes that affect the
database engine. A Database Server is isolated from the client application and does
not care if the client application is aborted or terminated by a user. VistaDB
must be very conservative in the writing of data to disk as a result of our engine
being embedded with your application. In the event of an abnormal termination
we must ensure data integrity to the VDB3 file on disk.
Database Servers also allow a much finer grain control for concurrency locking.
This is usually being handled by the central process that understands which threads
have locks on different database objects. We do not communicate between application
instances and must therefore provider lower level locking through the database on
disk, this is slower because the disk is the slowest IO device (usually). Most other
in-process (or Serverless) database engines do not allow multiple processes to update
the database for these design reasons. Embedded databases typically lock the
entire database per insert operation, we do not. We provide table and row
level locking.
Caching of requests is another large benefit to the Database Server scenario.
If multiple users ask the same question (or their queries use the same indexes),
the server process can load the data once and cache the output to the client.
VistaDB Server support?
We are often asked if we will support a VistaDB Server version. Yes, we have
one in the works. But we are not calling the first version a Server because
it will not support caching, query optimization, or user level access controls like
SQL Server. Our initial server-side application will be to get around the
file sharing limitations imposed by Windows and allow faster locking for quicker
multi process access to the database.