Skip to main content

PhoenixAI Anywhere

PhoenixAI Anywhere is the self-managed platform for running PhoenixAI entirely inside your own environment: your own cloud account, your data center, or a fully air-gapped network with no outbound connectivity.

Anywhere deploys PhoenixAI database clusters, scales and upgrades them, and keeps them running as nodes come and go underneath. It is delivered on Kubernetes and installed with Helm, and includes the Anywhere Console for managing clusters day to day.

These pages cover installing a PhoenixAI database cluster, connecting it to object storage, and operating it: deploying, configuring, scaling, and monitoring. They also cover using it: loading data, designing tables, querying data lakes, accelerating queries, and the SQL reference.

Start here

Pick the route that matches what you are doing.

If you want toStart with
See a working cluster end to end, on a cloud bucketQuick start with Amazon S3
See a working cluster end to end, with no cloud accountQuick start with MinIO
Install into a cluster you already runPrerequisites, then Install with Helm
Move off the open-source StarRocks operatorMigrate from the StarRocks operator
Look up a resource fieldCRD API reference
Look up SQL syntax, a function, or a system variableSQL reference

Either quick start installs a shared-data cluster, a warehouse, and the Anywhere Console in one pass, and ends with a cluster you can query. They differ only in where the data lives: an S3 bucket, or MinIO running inside the same Kubernetes cluster.

If you are handing the install to someone else, or to a service account, Least privilege to deploy lists the smallest set of Kubernetes permissions that works.

Consoles

Anywhere comes with two web consoles. The Anywhere Console manages clusters, licensing and usage. The Cluster Console is per cluster, for queries, catalogs and monitoring. The console tour walks through every page, who can reach it, and the path it lives at.

What's here

Get started — run a quick start end to end on the object storage you use, then tour the consoles.

Deploy — what to have ready, installing with Helm or with kubectl, migrating off the open-source StarRocks operator, warehouses, multiple clusters in one Kubernetes cluster, node disks, and operator upgrades.

Configure — the root password, TLS to the FE, persistent and CSI ephemeral volumes, external ConfigMaps and Secrets, and running with a read-only root filesystem.

  • Data Lakes — query data where it already lives, through external catalogs for Hive, Iceberg, Hudi, Delta Lake, Paimon, JDBC and more, plus external tables and the data cache that keeps repeat reads local.
  • Query Acceleration — materialized views, the cost-based optimizer and the statistics it needs, query and data caching, join and aggregation strategies, and the SQL Plan Manager.

Scale — add and remove capacity: autoscaling CN nodes with an HPA.

Operate — day-two work: loading with Stream Load, logging, expanding volumes, node maintenance and PodDisruptionBudgets, and restoring a cluster from a snapshot.

  • Data Loading — every route data takes in: object storage, HDFS and local files, Kafka, Spark, Flink and Pulsar, and INSERT, along with strict mode and transforming data as it loads.
  • Integrations — BI and IDE tools, streaming and batch connectors, loading and migration tools, dbt, Airflow, the JDBC driver, and authenticating to AWS, Azure and GCS.
  • Administration — FE and CN configuration, cluster management, backup and restore, resource management, audit logs, node blacklists, and data and metadata recovery.

Monitor — deploy Prometheus and Grafana, and wire a cluster up to them or to Datadog.

Best Practices — partitioning, bucketing, table clustering, Primary Key tables, authentication and authorization, and a query tuning guide built around reading the query profile.

Table Design — catalogs, databases and tables; the four table types; partitioning and bucketing; indexes, including full-text inverted and vector indexes; compression; and hybrid row-column storage.

Reference — the generated API reference for every custom resource the operator manages.

  • SQL reference — the SQL surface: data types, functions, statements, system variables and limits, information_schema, and the system metadatabase.

Versioning — what the five feature maturity levels mean, from experimental through to removed, and the maturity of each release.