Monday, March 30, 2009

Embedded vs. In-Memory vs. Server Databases

Software developers often interact with server oriented databases. However, there are at least two other types of databases, embedded and in-memory, which are less known to the software developer community. Here are the three types I would like to broadly classify the databases into:

a) Server Centric: They usually require a separate installation of the database server component. These are the most common types of databases, for example, SQL Server, Oracle, MySQL, Postgres, DB2, and so on. The database engine of these databases are hosted in a separate process. The applications trying to access data in these databases need to first connect using a database connectivity technology such as ODBC, OLE DB, ADO.Net, etc., and then execute SQL commands. The actual execution of the SQL queries are performed by the database engine.

b) Embedded: These databases do not require installation of any database components; often they are called as server-less or embedded databases. Some examples are SQLite, Firebird, MS Access, Derby, etc. The applications making use of these databases can create and manipulate databases from within their application itself, without requiring any additional software to be installed. These databases support SQL types command. There advantage is that they are easy to setup and require very little maintenance.

c) In-memory: These are the fastest of the breed. The database engine becomes part of the application accessing the database. Few common in-memory databases are Berkley DB, Microsoft's ESENT, Perst, etc. In order to make the data access faster, these databases do not provide support for SQL type command. In any other database type, the support of SQL forces additional layer of parsing to perform data access, and hence make them slower as compared with in-memory datavase. In fact, applications are required to use special APIs to access and manipulate data.

The in-memory databases are hardest to implement, although they have the best performance. However, there are wrappers available to ease out the development process, but still they do require additional work on the developer's end.

2 comments:

steve said...

Hi Ashish,

I like to suggest some refinements to your summary.

Another term for 'embedded' is 'in-process' database system. Both of McObject's database systems are embedded/in-process: eXtremeDB and Perst.

Embedded databases may, or may not, support the SQL API. (eXtremeDB offers it as an option, Perst has minimal support for SQL).

While it's useful to have a separate category for in-memory databases, it is also important to recognize that in-memory databases can be either server-centric or embedded. eXtremeDB is an in-memory embedded database system.

It is also true that some database systems can be both in-memory and file system-based. You included Perst in the in-memory database category, which is correct because Perst can operate in this manner. But Perst is not a native in-memory database, whereas eXtremeDB is a native in-memory database and eXtremeDB Fusion offers both in-memory and file system-based storage.

I hope you and your readers find this information useful.

Steve Graves, president
McObject LLC

Ashish Prasad said...

Hi Steve,

Appreciate you coming to the blog and offering your suggestion. I will update the blog per your suggestions.

Cheers,
Ashish