Database

In our stack, there’s already a component for storing data: the database. As PostgreSQL¹ also has support for storing binary data types with arbitrary data, it may seem logical to also use it for storing binary files. After all, that results in one less component to worry about.

Overview

Comparison

Each of the requirements is scored on a scale from 1 (very poor) to 5 (very good).

Total size

Score: 3. Although the database should be able to store terabytes worth of data, disk and database limits can cause issues beyond that.

Item size

Score: 4. Standard binary data types in PostgreSQL have size limits of 1GB, which may not be enough in some cases. However, PostgreSQL also has a Large Objects feature, which can automatically chunk data and support larger files by storing them in a separate system.

Performance

Score: 1. Having to read and write larger amounts of binary data to and from the database can result in a much larger strain on its connection, which can also affect performance of normal queries.

Using the database for binary data results in a much larger strain on the database system, which can also affect performance of normal queries.

Accessing data

Score: 2. Through PostgreSQL clients and libraries, the data can be retrieved as a stream, and then served to the clients.

JavaScript support

Score: 2. Although there are JavaScript libraries² available for PostgreSQL, support for large objects is limited to a single, unmaintained library.

Scalability

Score: 1. PostgreSQL is limitid in its capabilities for scaling. In addition, large objects are stored in a system table and therefore not replicated.

Portability

Score: 2. The database server can be connected to by another server. Transferring the data over to another database can be a difficult and manual process.