Quasar's Architecture
● System Overview
Quasar is a distributed operational data platform designed to ingest, store, and query large-scale numerical and time-series data in a single system.
A Quasar cluster is composed of compute nodes responsible for ingestion, storage, and distributed query execution. Each node participates directly in the write path, storage engine, and query engine, allowing the system to scale horizontally without separating real-time and historical workloads.
The storage engine uses compressed columnar storage with transparent tiering across attached and external storage. Queries are executed directly against the live distributed dataset through native APIs, SQL interfaces, or optional OLAP nodes running DuckDB for read-intensive analytical workloads.
Unlike architectures that separate ingestion pipelines, historians, warehouses, and serving layers, Quasar operates as one unified system with a single underlying dataset.
Key components
- Unified compute nodes for ingestion, storage, and query execution
- Distributed columnar storage with built-in compression and transparent tiering
- Native distributed query engine
- Optional OLAP nodes for high-concurrency analytical workloads
- SQL, API, dashboard, and AI/ML integrations
● Data Flow & Storage
Quasar is designed so data becomes usable as soon as it enters the system. Incoming writes are validated, acknowledged, and made available to the query engine immediately, while the storage engine organizes the data for long-term scale.
Data flows through an LSM-based mutable write path optimized for sustained ingestion. Unlike append-only systems, Quasar supports updates, corrections, and deletes while preserving durability and consistency.
Once written, data is partitioned using a configurable single or composite primary key and distributed across the cluster. Each partition is stored in compressed columnar format and can be transparently tiered across local and capacity storage without changing how queries access it.
Key properties
- Data is queryable immediately after acknowledgment
- LSM-based mutable write path
- Supports updates, corrections, and deletes
- Configurable single or composite primary key partitioning
- Distributed partitions across the cluster
- Compressed columnar storage
- Transparent tiering across attached, detached, and object storage
● Query Execution
Query Execution
Quasar provides two complementary ways to query the same underlying distributed dataset: the native Quasar query engine and the DuckDB OLAP path. Both operate on live and historical data without requiring separate copies or pre-aggregated datasets.
One dataset, two execution models
The two paths are complementary. Native Quasar queries provide maximum speed and direct distributed execution, while DuckDB provides standard SQL and OLAP compatibility. Both access the same real-time and historical data, avoiding duplication, drift, and separate serving layers.
Native Quasar Queries
The native query engine is designed for maximum performance and direct control. Queries are planned against the relevant partitions, distributed across the cluster, and executed in parallel on Quasar nodes before results are merged into a single response.
This path is best for:
- Low-latency operational queries
- High-throughput analytical operations
- Custom distributed computation
- Workloads that need capabilities beyond standard SQL
DuckDB Queries
For full SQL and OLAP workloads, Quasar can be queried through DuckDB using a high-performance plugin. DuckDB parses and plans analytical queries, while filters, scans, and projections are pushed down to Quasar whenever possible. Quasar returns the relevant data efficiently, and DuckDB completes the remaining OLAP operations.
This path is best for:
- Full SQL analytics
- BI and dashboard workloads
- Ad-hoc exploration
- Joins, aggregations, window functions, and ecosystem compatibility
● Integration in your architecture
Quasar is designed to fit into existing architectures without requiring a full platform migration. You can deploy it alongside existing databases, historians, streaming systems, and analytical tools, then move workloads gradually as value is proven.
Data can be ingested directly from operational systems, streaming platforms, market feeds, existing databases, or historical imports. Downstream teams can continue using familiar tools through SQL, APIs, dashboards, BI platforms, AI pipelines, or custom applications.
Teams typically start with a targeted workload, then expand Quasar over time into the single source of truth for real-time and historical data.
Typical integration patterns
- Start with a targeted workload, then expand Quasar as the operational source of truth
- Ingest live streams and historical backfills into the same system
- Keep existing BI, dashboard, and application workflows
- Access data through SQL, APIs, connectors, or native interfaces
- Gradually replace fragmented pipelines where Quasar becomes the better system
- Integration with analytics, dashboards, and AI workloads
