adb, the database behind Arize AX

Every trace you send to Arize AX, every evaluation you run, and every annotation you add is stored in adb, Arize’s proprietary, AI-native online analytical processing (OLAP) database. adb is the engine behind every managed Arize AX instance, processing terabytes of data daily and billions of spans and traces monthly, at petabyte scale with sub-second latency.

​

Why Arize built adb

AI observability depends on fast ad-hoc analytics over high-volume generative AI data, fresh events available within seconds, and mass updates when you re-run evaluations on historical traces. Traditional databases weren’t built for this combination at petabyte scale, so Arize built adb to serve all of it at once. The guiding principle is an anti-monolith approach: instead of one all-in-one system, adb is a universal data layer built on open standard formats (Parquet, Iceberg), with lightweight, stateless query engines sitting on top of shared object storage. Data Fabric can continuously sync your traces, evaluations, and annotations to your own cloud warehouse, like BigQuery or Snowflake, in open Iceberg format. adb’s architecture is shaped around five goals:

1. Core data asset. Keep generative outputs in open formats (Parquet, Iceberg) so they’re accessible to any tool, with no vendor lock-in.
2. Stateless, elastic compute. Separate storage from compute so query engines can scale and move without relocating or losing data.
3. Sub-second performance. Maintain spreadsheet-like responsiveness even at billion-row scale.
4. Continuous real-time updates. Stream fresh events in without blocking historical backfills, and capture evaluations and annotations on data of any age.
5. Internet-scale durability. Reliably process billions of spans and traces per month across hundreds of customers.

​

Architecture

adb’s architecture follows from the decision to separate storage from compute: data lives in object storage as open, columnar files, while the query engines that read it are lightweight and stateless. Because the engines hold no permanent state, they can scale up under load, scale down when idle, and move between machines without relocating or losing data. Data reaches storage along one of two write paths, depending on how it arrives:

• Streaming path, for live events. Incoming events land in the query layer (the tier that also serves historical reads), where they’re materialized as in-memory Arrow data so they’re queryable immediately.
• Batch path, for large backfills. Large uploads bypass the query layer entirely and write Parquet/Arrow files directly to blob storage. An indexing service then generates the metadata needed so those files are queryable through the same interface as streamed data.

Both paths converge on the same open file formats in object storage, so a query sees streamed events and backfilled history as one unified dataset.

​

Real-time ingestion

adb ingests both large file uploads and continuous streams of trace events at scale, terabytes a day across billions of spans. For streaming, a record becomes queryable from the moment it arrives in memory rather than after a scheduled batch job runs. Incoming records accumulate in memory, where they immediately become available to queries. Periodically they’re flushed to local disk, and from there synchronized to cloud blob storage for durable, long-term storage.

​

Delivery guarantees

adb offers two levels of guarantee for streamed records:

• At-least-once delivery. A record is acknowledged only after it has been durably persisted, and if a client doesn’t receive an acknowledgment it retries, so no record is silently lost.
• Effectively-once ingest. adb keeps track of what it has already saved, so if part of the pipeline retries after a failure, it resumes from the last saved record instead of writing the same record twice.

A distributed write-ahead log (WAL) sits behind the stateless ingestion edge (the layer that accepts incoming records). The WAL lets clients meet their retry and persistence requirements before records are fully ingested into adb, keeping the ingestion edge stateless without sacrificing durability.

​

Performance & benchmarks

The benchmarks measure the operations users experience most directly: how fast data uploads, how quickly a trace goes from ingested to visible, and search latency over large datasets. Tests were run over a 150 MB/s down / 150 MB/s up connection; full-text search was measured as regexp search over datasets of 5M and 10M spans, each span carrying a ~25 KB chat-text string. The adb (P50) column is the median database timing, Arize AX Platform is the end-to-end time a user sees (database plus application), and Platform A, Platform B, and Platform C are other observability platforms run through the same tests. Across every category, adb’s raw database timings stay in the sub-second range even as row counts grow into the millions, and the end-to-end Arize AX platform stays fast where other platforms rate-limit, cap file sizes, drop records, or fail outright. Several platforms that remain close to adb on small trace batches become tens to hundreds of times slower, or stop working, as data volume grows.

​

Self-hosting

If you self-host Arize AX, adb runs as the “ArizeDB” component in your cluster. See the self-hosting prerequisites for its node-pool and storage requirements.

​

Learn more