PhoenixAI Database
Sub-second queries across streaming and lakehouse data, at the concurrency AI agents and customer-facing analytics demand. Fully managed inside your own cloud, or self-hosted.
What it is
PhoenixAI is a real-time analytical database for AI agents and customer-facing analytics. It serves sub-second SQL across streaming data and your Apache Iceberg lakehouse, with minimal data movement.
It handles workloads that break other databases: agent queries needing sub-second answers, complex multi-table joins on fresh data, and customer-facing analytics at tens of thousands of QPS. Standard SQL throughout, so existing tools connect without rewrites.
<1s
Query latency
on multi-table analytical queries
<5s
Ingest to queryable
on streaming mutable data
10K+
QPS
Sustained load
90%
Lower infrastructure footprint
than other real-time analytics solutions
Core capabilities
Four things PhoenixAI is built to do, at the scale AI workloads demand.
PhoenixAI keeps query latency under a second across both freshly streamed data and historical lakehouse data, under the high concurrency AI agents and customer-facing analytics demand. Latency stays stable whether traffic is hundreds of QPS or tens of thousands.
AI agents and dashboards issue queries you can’t always plan for. PhoenixAI runs multi-table joins on the fly against normalized schemas, with no need to pre-flatten or pre-aggregate. Materialized views stay available as optional accelerators for the heaviest repeat patterns, not as a mandatory starting point.
PhoenixAI sits alongside the infrastructure you already have. Query your lakehouse in place, ingest streams as they arrive, and connect through standard SQL, without rewriting queries, replacing tools, or copying data into a separate warehouse.
The full PhoenixAI engine, not a stripped-down edition. Kubernetes-native automation and self-healing operations let your platform team run it entirely inside your own environment — without taking on manual ops.
How it works
The optimizer picks join strategies, predicate push-downs, and execution paths based on actual data statistics at runtime. Multi-table joins that time out elsewhere complete in well under a second, without manual hints or query rewrites.
PhoenixAI’s query engine processes data in column-oriented batches using SIMD CPU instructions. On complex aggregations and scans across billions of rows, this translates directly into sub-second response times.
Massively parallel processing compute architecture distributes joins and aggregations across every node in the cluster. Complex multi-table joins on large fact and dimension tables scale out as the dataset grows, with no need to pre-aggregate or denormalize by default.
Works with
In production
Coinbase's blockchain dataset spans hundreds of billions of rows across more than 300 normalized tables. Our fraud and compliance workloads require complex joins, and blockchain network analytics demand low-latency query performance that our previous query engines could not provide. PhoenixAI changed the equation: streaming updates from Kafka become queryable within seconds, analysts get sub-second responses on live normalized data, and our AI agents operate on the same real-time dataset. This level of performance at scale fundamentally changes what data teams can do.
Coinbase
PhoenixAI customer
>300
Normalise tables
PhoenixAI is at the center of our real-time data analytics. We strive for quicker and easier insights into day to day operations. We chose PhoenixAI for its ability to upsert data in real-time, support for joins across large fact tables with very low latency, and the ability to serve and join native and external tables from the same cluster.
Fanatics
PhoenixAI customer
<1s
join latency
Demandbase AI introduced unpredictable LLM-generated SQL that our previous ClickHouse-based architecture wasn’t built to handle. PhoenixAI gives us a fast, isolated warehouse for agent workloads directly on our Apache Iceberg tables, with the optimizer handling novel joins automatically. Our agents now query petabytes of normalized data across thousands of tenants while customer-facing dashboards keep their second-level SLAs.
Ryan Nowacoski
Senior Engineering Manager, Data Platform, Demandbase
Petabytes
agent workloads
