Joins without flattening
Multi-table joins on normalized schemas come back in under a second, so you can skip the wide tables.
From the creators of StarRocks
PhoenixAI created StarRocks and leads its development. PhoenixAI is built on that core and adds what production asks for: cell-level access control, workload isolation, high availability, and support with an SLA.
Trusted by teams running StarRocks in production
New to StarRocks?
An open-source analytical database for sub-second queries on live data. Pinterest, Trip.com, Tencent, and Shopee run it in production.
Multi-table joins on normalized schemas come back in under a second, so you can skip the wide tables.
Rows from Kafka or Flink CDC are queryable within seconds, including updates and deletes.
Reads Iceberg, Delta Lake, and Hive tables where they are. Connects over the MySQL protocol, so your current tools work.
Already running StarRocks?
StarRocks is a capable database on its own. What it does not include is the list your security review and your on-call team will hand you before go-live: row and column policies, Kerberos and SSO, compute that agents cannot steal from BI, a second availability zone, and upgrades nobody has to babysit. That list is what PhoenixAI is.
Open-source StarRocks
PhoenixAI
The feature gap
| Capability | PhoenixAI | StarRocks (open source) |
|---|---|---|
| Core engine | Built on StarRocks. SQL, schemas, and connectors carry over. | The StarRocks engine. |
| Access control | Row access and column masking policies, native, applied at query time. | RBAC and column privileges. Row and masking policies only through an external Apache Ranger deployment. |
| Authentication and encryption | Kerberos, LDAP, and SSO from the console. Transparent data encryption. Vulnerability management. | Native, LDAP, OAuth 2.0, and JWT, configured by hand. Kerberos and encryption at rest are not available. |
| Workload isolation | Multi-warehouse: agents, BI, and ETL each get their own compute, with autoscaling. | Resource groups share one pool of compute inside a cluster. |
| High availability | Multi-AZ, cache high availability with automatic warmup, cross-cluster replication. | Replicas inside a single cluster. |
| Operations | Automated upgrades, patching, backups, and failure recovery. Console with monitoring, alerting, and graphical query profiling. | Upgrades and backups are manual. Metrics endpoints; you build the dashboards. |
| Lakehouse and materialized views | Unity Catalog, Iceberg V3, incremental materialized views, automatic MV recommendation. | Iceberg V2, Delta Lake, Hive. Materialized views you design and refresh yourself. |
| Support and compliance | 24/7 support with an SLA from the engineers who write StarRocks. SOC 2 Type 2 and GDPR. | Community Slack and GitHub issues. |
From the PhoenixAI Cloud and PhoenixAI Anywhere documentation, September 2026.
Two ways to run it
The same enterprise feature set, including vector and BM25 text search. Pick who operates it and where the data stays.
Fully managed by the team behind StarRocks. Clusters in minutes, upgrades handled for you, pay only while a cluster is running.
Self-managed inside your cloud account, data center, or air-gapped network. Runs on Kubernetes, installs with Helm, and nothing calls home.
Cloud and Anywhere side by side, with what each plan includes.
Open source and commercial
Yes. StarRocks is a Linux Foundation project under the Apache 2.0 license.
Yes. PhoenixAI is built on StarRocks. Your SQL, schemas, and connectors carry over, and most teams run both side by side while they compare.
In the docs. The PhoenixAI Cloud and PhoenixAI Anywhere pages each have a table comparing every capability with open-source StarRocks.
You are not buying into a proprietary query language or a closed engine. The SQL and schemas you write on PhoenixAI stay compatible with the open-source project.
Yes. PhoenixAI Anywhere runs in your cloud account or data center with full, allowlisted, or no outbound connectivity. Licenses validate offline.