NexusDB

BLOB: Short for Binary Large Object, a collection of binary data stored as a single entity in a database management system. BLOBs are used primarily to hold multimedia objects such as images, videos, and sound, though they can also be used to store programs or even fragments of code.

Are blobs stored internally to the table always loaded into memory?

Like everything else, the blob engine uses the buffer manager to access the table, blobs are stored in "segments" (variable sized parts of blocks allocated through the "heap engine"), these segments are organized in a b-tree with actual blob data stored in the leaf nodes of the tree. Blobs are only loaded into the server's memory if client code specifically reads or writes blobs.

At the server engine level blobs are almost completely independent of records. A quick look at nxsdServerEngine.pas will reveal the functions for blob handling. Each of these functions will start and commit a (implicit) transaction if there is no transaction already active. As a user of NexusDB you normally never call these functions directly, instead the TnxBlobStream class encapsulates the calls to these functions and provides a Delphi typical TStream interface.

In the record buffer each blob field is represented as a 64bit value. The meaning of this value is defined by the specific blob engine used by the table. (Currently there's only one blob engine implemented, but there might be additional ones in the future.)

When a blob is edited on the client side, changes are immediately sent to the server. The changes are held in memory until the current edit/insert operation is either commited (changes are written to disk) or rolled back (changes are discarded).