Time-Series Engine
Alopex Skulk
A time-series engine without the server
Using a time-series database should not require standing up and operating a server. Skulk is embedded in an application as a library. There is no additional operational target, and you still distribute one binary—the same binary can run on edge and embedded devices.
An embeddable time-series engine that removes the need to operate a server just for metrics.
- Binary size
- 3.7 MB
- Ingestion protocols
- 3
Key points
- No additional process to operate
- Embedding it does not bloat the application
- Stored Parquet remains directly readable by other tools
Challenge
There is no one time-series DB from embedded devices to clusters
A time-series DB that runs on an edge device and one operated as a cluster are different products. Every change in scale means changing products, moving data, and rewriting queries. Skulk aims to cover embedded deployments through clusters with one engine.
- There are very few time-series DB choices that run on edge and embedded devices
- A product that starts as a single node does not automatically become a cluster
- Every scale change brings data migration and query rewrites
Skulk is embedded in an application. It needs no server or daemon. Because it uses Arrow and Parquet without embedding a query engine, it stays small when included in an application, and other tools can read its stored Parquet directly. Distribution runs on the cluster foundation it shares with Alopex DB, so the engine stays the same as scale changes.
Its SQL and PromQL parsers are written in Nim and share the Alopex DB implementation. In AST-heavy parsing work, Nim was 46% faster than Rust (details).
Skulk handles time-series data. For event logs, use Trail; Alopex OTel brings both together with dashboards.
One engine from embedded to distributed
Skulk is a library embedded in a single process—no server or daemon required. When requirements grow, distributed capabilities run on Chirps, the cluster foundation shared with Alopex DB.
- A 3.7 MB library that can ship inside an application binary
- Arrow + Parquet keeps stored data directly readable by other tools
- Three ingestion protocols let existing agents send data unchanged
- Required processes
- 1
- Compression improvement (repeated values)
- 7.1×
Capabilities
Three ways to use it
Use the same engine differently as requirements grow.
Embed it in an application
For edge devices and single-process applications
- Link it as a library—no server to run
- Distribute it within the application binary
- Read stored Parquet locally with other tools
Run it as a single node
For development environments and small-scale monitoring
- Accept writes from multiple processes through an HTTP server
- Ingest simply by pointing existing agents at it
- Query with SQL and PromQL
Expand to a cluster
For production workloads that need redundancy
- Distribute over Chirps, shared with Alopex DB
- Expand an embedded deployment without changing the architecture
- Keep queries unchanged as scale changes
Features
Key features
What Skulk provides to store and read time-series data.
Three ingestion protocols
Supports InfluxDB Line Protocol, Prometheus Remote Write, and JSON. Point existing agents at it to ingest data.
Time partitioning and TTL
Store data in time-based partitions and automatically remove expired data. No separate retention-management mechanism is needed.
Highly compressed columnar storage
Compared with v0.2, repetitive values use 7.1× less space and highly variable gauges use 1.6× less. Retain more history on the same disk.
Parquet readable by external tools
Data stays in Parquet, so analysis needs no export step.
SQL and PromQL queries
Shares Alopex DB's Nim parsers. In work that creates many AST nodes, Nim was 46% faster than Rust.
Distribution on Chirps
Distribution and replication run on Chirps, the cluster foundation shared with Alopex DB. Start embedded and expand the same deployment.
Tech Stack
Technology stack
Shares components with the Alopex family.
Storage
Apache Arrow + Apache Parquet
Queries
Nim-based parsers
Cluster
Chirps: SWIM + QUIC
Status
Development status
v0.3.0 was released on July 28, 2026 and is available on crates.io. v0.3.1 focuses on ingestion-performance optimization. Query execution is planned for v0.4, downsampling for v0.5, an HTTP server for v0.6, and distribution and replication from v0.8 onward. The v0.4 query layer shares Alopex DB's Nim SQL parser and implements the PromQL parser in Nim.
Public Resources
The latest documents, code, and community links in one place.
Get Involved
Try it and tell us where it gets stuck
If an ingestion protocol or storage behavior gets in the way, please open an issue.