Time Series Database

IronDB

Faster, Efficient, and Easier to Operate and Scale

Apica’s IronDB is a Time Series Database (TSDB) that offers unparalleled reliability, scalability, and speed, addressing the core needs of modern IT monitoring. It enables you to manage large-scale installations with millions of time series efficiently, ensuring that monitoring practices keep pace with the rapid evolution of technology and the increasing sophistication of cyber threats.

The Problem

Is limited visibility, data volume, and performant data hindering your IT monitoring?

Cardinality Pricing Traps

Competing platforms tie cardinality limits to pricing tiers, forcing impossible trade-offs between monitoring granularity and budget.

Query Performance Degradation

Traditional TSDBs slow to a crawl under high-cardinality workloads — returning results in minutes for queries that should take milliseconds.

Exponential Cost Scaling

Per-metric and per-custom-metric pricing models penalize cloud-native architectures, with costs growing 250% year-over-year as infrastructure scales.

Premature Aggregation

Teams forced to aggregate data at collection time destroy granularity and create blind spots that prevent accurate root cause analysis

Tag Anxiety

Engineers self-censor meaningful metric labels to stay within cardinality budgets, reducing the observability value of every data point collected.

Benefits

We Can Help. See How.

Enhanced Monitoring Capabilities

Apica provides a Time Series Database (TSDB) that is reliable, scalable, and fast, improving visibility across IT operations.

Seamless Data Integration

The recent enhancements enable ingestion of various data sources, facilitating interoperability with existing monitoring systems.

Robust Data Management

Features like data replication and clustering ensure that your telemetry data is always available, even during outages or maintenance.

How It Works

Integration and Scalability Basis

Apica's IronDB TSDB has evolved to support the Graphite data format on ingestion, enhancing its capability to work alongside other data collection tools and monitoring systems. This advancement enables organizations to overcome the challenges of scaling and maintaining high availability metrics infrastructure, particularly during data surges, outages, or routine maintenance.

Proven Business Outcomes

Production-Validated at Enterprise Scale

IronDB is not a new product. It has been battle-tested in production environments handling some of the most demanding cardinality workloads in cloud-native infrastructure.

Case Study

Enterprise Cloud-Native Platform

Large-scale Kubernetes deployment generating tens of millions of unique metric streams. Existing platform imposing cardinality limits and forcing tag dimensionality compromises that degraded incident response.

10–15× increase in metric cardinality without performance impact
Eliminated all tag dimensionality compromises — every label retained
60–70% reduction in metrics infrastructure costs
Engineers no longer self-censoring labels to stay within cardinality budgets

Case Study

Multi-Cloud Enterprise (AWS / Azure / GCP)

Hybrid multi-cloud infrastructure with Istio/Envoy service mesh observability generating extreme tag cardinality. Prometheus federation approach couldn’t scale past 30-day retention across 200+ instances.

Centralized metrics from 200+ Prometheus instances across 3 cloud providers
Extended data retention from 30 days to 2 years without storage cost explosion</li?
Enabled cross-cloud capacity planning and year-over-year trend analysis
Sub-100ms query latency maintained across entire multi-cloud footprint

Features

A whole spectrum of practical features

Replication Strategies

A common challenge in managing time series databases, like Graphite, involves the handling of nodes. The risk of data loss or inaccessibility during node outages, whether due to failure or maintenance, poses significant concerns. Traditional time series databases (TSDBs) may suffer from data unavailability and alerting issues during these periods.

IRONdb addresses this issue by maintaining multiple data copies across a cluster of nodes. When data enters, it is stored on the designated local node and simultaneously sent to other nodes based on predefined replication settings. This process, which runs in the background, ensures data availability even if a node goes offline.

Multi-Data Center Support

Building on its robust replication capabilities, IRONdb supports deployments across multiple data centers, ensuring data resides on nodes across different network segments or “Availability Zones.” This setup allows for continuous data availability and query capabilities, even if an entire zone goes offline. Upon recovery, downed nodes automatically sync missing data through background replication processes.

IRONdb’s distributed nature means data queries can be made to any node in the cluster, which will either fulfill the request with local data or reach out to other nodes for the required information. This flexibility, however, may be affected by the physical distance between data centers, potentially impacting data retrieval times.

Performance Insights

Performance metrics for databases can vary widely based on numerous factors, including hardware and data characteristics. While benchmarks provide a comparative insight, IRONdb encourages personal testing to gauge performance accurately.

In tests comparing IRONdb to other databases, IRONdb showed promising ingestion rates, potentially outperforming competitors under certain conditions. The results underscore IRONdb’s efficiency, especially when minimizing network latency in data transmission.

Data Integrity and Efficiency

IRONdb utilizes OmniOS and ZFS for its underlying file system, which offers advanced data protection, integrity checks, and compression capabilities. ZFS’s design to detect and correct data corruption ensures that IRONdb maintains high data integrity. Additionally, ZFS supports mirroring and striping, enhancing data resilience, and offers significant storage capacity with efficient space utilization through compression technologies.

Administration and Compatibility

IRONdb provides an administrative interface for insights into node activities, including ingestion rates, storage information, and replication latency. The UI also offers a detailed view of the database’s internal operations, aiding in performance optimization.

For Graphite users, IRONdb is compatible with Graphite-web 0.10 and later versions, offering a seamless integration path through a storage finder plugin. This compatibility extends to Grafana, allowing the use of Graphite as a data source for comprehensive data visualization and analysis.

Integrations

Graphite Data Format Support

Directly ingests and processes data in the Graphite format, streamlining data management for organizations using Graphite.

Compatibility with Graphite-web and Grafana

Facilitates easy integration into existing monitoring setups, enhancing the utility and extending the functionality of current systems without requiring significant changes or overhauls.

FAQ

Frequently Asked Questions

How does IronDB handle high-cardinality workloads differently than traditional TSDBs?

Traditional TSDBs were designed for relatively low cardinality and bolt on high-cardinality support as an afterthought — imposing artificial limits, degrading query performance, or charging exponential overages. IronDB’s tag-first indexing engine and distributed architecture were designed from the ground up for billions of unique metric streams. This means you get consistent sub-100ms query latency and no cardinality caps, even as your Kubernetes pods, microservices, and multi-cloud dimensions multiply.

What does "histogram-native storage" mean in practice?

Instead of storing every individual measurement (raw samples), IronDB natively stores data in histogram buckets. This enables accurate P50, P95, P99, and P99.9 percentile calculations without requiring you to retain millions of raw data points. The result is 10–100× storage reduction while maintaining the statistical accuracy your SREs need for latency analysis, SLO calculations, and anomaly detection.

Can IronDB replace our existing Prometheus setup?

Yes. IronDB can serve as a long-term storage backend for Prometheus, replacing the 30-day retention limit that most teams hit as their infrastructure scales. One multi-cloud enterprise used IronDB to centralize 200+ Prometheus instances across AWS, Azure, and GCP — extending retention from 30 days to 2 years while maintaining sub-100ms query latency across their entire footprint. Your existing Prometheus configuration, exporters, and PromQL tooling continue to work.

Is IronDB available on-premises, in the cloud, or both?

IronDB supports flexible deployment models including on-premises, cloud, and multi-datacenter hybrid configurations. The distributed architecture allows you to deploy across availability zones and cloud providers simultaneously. Fast deployment means installation takes minutes with a single command, and scaling is a single operation — no complex cluster management required.

What does IronDB's pricing model look like?

IronDB uses consumption-aligned, capacity-based pricing agreements — not per-metric or per-custom-metric pricing. This means your costs don’t grow exponentially as your infrastructure scales. The capacity-based model provides cost predictability while supporting substantial infrastructure growth within contracted parameters. Contact your Apica representative for a customized quote based on your specific requirements.

Does IronDB integrate with Grafana and our existing dashboards?

Yes. IronDB ships with a native Grafana data source plugin that allows you to expand your metrics capacity without changing your visualization stack. It also provides full Graphite-web compatibility (0.10 and later), making it a drop-in solution for organizations already running Graphite. Your existing dashboards, alerts, and queries continue to function — IronDB simply removes the cardinality and cost constraints.