Serverless VistaDB

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.