Why ApertureDB?

Multimodal applications work with related data in different forms: images and videos, descriptive metadata, annotations, and feature vectors. A query may need several of these together, such as images with a particular label that are also similar to a reference image.

Managing these relationships involves tasks such as:

• Storing different types of media and metadata.
• Searching and displaying the matching data.
• Tracking datasets and annotations.
• Inspecting model results alongside their training data.
• Selecting new data for retraining.
• Supplying data to production inference jobs.

The data-management overview describes these recurring tasks.

Separate storage and search components

An application can store media in files or cloud buckets, metadata in a database, and embeddings in a vector index. Each component handles part of the workload. The application must maintain the relationships between them and combine their results.

Figure 1: Separate storage, search, and processing components connected by application integrations.

For example, labeling produces annotations that must remain associated with the source images. Training jobs select images and labels, decode the media, and apply transformations required by the model. Similarity queries also need to connect vector-search results back to the corresponding media and metadata.

Libraries such as OpenCV and ffmpeg provide media processing. A system using separate storage and search services needs application code to coordinate these operations, track object identities, and handle changes to each dataset.

Combined storage, search, and processing

ApertureDB represents media, metadata, annotations, and embeddings as connected objects. A query can combine their properties and relationships with vector similarity search, then return the matching metadata and media. Image and video operations run as part of ingestion or retrieval.

Figure 2: ApertureDB combines storage, search, and media processing behind one query interface.

This design moves coordination between data types into the database. Applications request the data needed for a task without independently joining results from several stores. Processing near storage can also reduce transfers when only a region, frame, or transformed image is needed.

Reported dataset-creation speedups of up to 35 times depend on query complexity and workload (VLDB'21). Application performance depends on the queries, stored data, and provisioned resources.