Checkpoints

It is unclear if BlazingSQL supports checkpointing.

Compression[03][04][05][06][07]

BlazingSQL supports compressing and decompressing directly on the GPU. It accepts a variety of input formats such as Apache Parquet, BlazingDB Simpatico (GPU-compressed distributed files), and GDF (GPU dataframes built on Apache Arrow). Data is then sent to the GPU compressed.

Concurrency Control

It is unclear what forms of concurrency control are in place for BlazingSQL.

Data Model

BlazingSQL

Hardware Acceleration

Indexes

BlazingSQL does not appear to support indexes.

Isolation Levels[08]

BlazingSQL supports Snapshot Isolation, it is unclear if other options are supported.

Joins[09][10]

BlazingSQL supports hash joins, e.g. on strings. It is not clear what other join types are supported.

Query Execution[11]

BlazingSQL operations are vectorized on the GPU (SIMD).

Query Interface[03]

BlazingSQL exposes a Python connector for executing SQL commands.

Storage Architecture

Storage Model[07][12]

BlazingSQL is a column-store. To execute a query, it compresses and transmits relevant columns to the GPU. On the GPU, data is represented as a GPU DataFrame (GDF). GDFs are built on top of Apache Arrow, which is a columnar in-memory format.

Storage Organization[13]

BlazingSQL appears to be log-structured as it did not previously have support for update and delete, but this is uncertain.

Stored Procedures[09]

As of BlazingSQL 1.3, stored procedures do not appear to be supported.

System Architecture[14][15][16]

BlazingSQL worker nodes push information to each other whenever required. There is a notion of a distributed cache, and nodes can ask each other for cached data lake data.

Views[17]

BlazingSQL 1.3 supported the CREATE VIEW command. It is unclear if the views are virtual or materialized.