StarRocks

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_D4s_v5 (4 vCPU / 16 GiB RAM) is the recommended starting size. See Sizing for the reasoning and the measured figures.

In the NSG, allow inbound 22/tcp from your management network. No inbound application ports are needed, because you reach the database over the SSH tunnel.

Install a MySQL command-line client on the machine you connect from. StarRocks implements the mysql_native_password authentication plugin, so use a MySQL 8.0.30+ client or a MariaDB client. MySQL 9.0 and later clients removed that plugin and cannot connect. On macOS in particular, prefer mariadb-client over a 9.x mysql-client.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for StarRocks by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size (Standard_D4s_v5 or larger). Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) only. Then select Review + create and Create.

First-boot initialization generates your per-VM root password, starts the Frontend and Backend, and registers the Backend with the Frontend. It then verifies that the cluster answers a query. Allow a minute or so after the VM is running before the database accepts connections.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms, then create the VM:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:starrocks-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name starrocks \
  --image sac1647283583153:starrocks-ubuntu-24-04:default:latest \
  --size Standard_D4s_v5 \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

Connect over SSH:

ssh azureuser@<vm-public-ip>

A welcome banner prints the most useful commands. StarRocks runs as two system services, starrocks-fe and starrocks-be.

Step 4 - Confirm the database is running

Check both services:

systemctl is-active starrocks-fe starrocks-be

Both services should report active:

active active

The dedicated data disk holds the Frontend metadata and all Backend tablet data at /var/lib/starrocks. Confirm that it is mounted:

df -h /var/lib/starrocks | tail -1

/dev/sdc 63G 80M 60G 1% /var/lib/starrocks

Step 5 - Retrieve your per-VM database password

The first boot generates a unique password for this VM and writes it to a root-only file. Read it as root:

sudo cat /root/starrocks-credentials.txt

# StarRocks 3.5.19 — generated on first boot by starrocks-firstboot.service
# These credentials are unique to this VM. Store them somewhere safe. starrocks.host=<your-vm-ip> starrocks.port=9030 starrocks.root.user=root starrocks.root.password=<your-unique-password>

Confirm that only root can read the file:

ls -l /root/starrocks-credentials.txt

-rw------- 1 root root 831 Jul 20 08:33 /root/starrocks-credentials.txt

Step 6 - Connect and run SQL

Connect with any MySQL client. On the VM itself, run:

mysql -h 127.0.0.1 -P 9030 -uroot -p

Confirm the version:

mysql> SELECT current_version();

current_version() 3.5.19-7dd233e

Create a table, insert rows and query them back. StarRocks requires a distribution key on CREATE TABLE. On a single-node image, set replication_num to 1:

CREATE DATABASE IF NOT EXISTS demo; USE demo; CREATE TABLE events (id INT, name VARCHAR(64), amount INT) DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 3 PROPERTIES('replication_num'='1'); INSERT INTO events VALUES (1,'signup',100),(2,'purchase',250),(3,'signup',75); SELECT * FROM demo.events ORDER BY id;

id name amount 1 signup 100 2 purchase 250 3 signup 75

Run an aggregate, the kind of work StarRocks is built to do quickly:

SELECT name, COUNT(*) AS n, SUM(amount) AS total FROM demo.events GROUP BY name ORDER BY total DESC;

name n total purchase 1 250 signup 2 175

Step 7 - Verify the security posture

Confirm that your VM refuses the empty password that upstream ships with:

mysql -h 127.0.0.1 -P 9030 -uroot -e 'SELECT 1' >/dev/null 2>&1 \
  && echo "ACCEPTED - INSECURE, contact support" \
  || echo "REJECTED - correct, the empty password does not authenticate"

REJECTED - correct, the empty password does not authenticate

Run without the guard, the same connection prints the server's own refusal:

ERROR 1045 (28000): Access denied for user 'root' (using password: NO)

Confirm that the two Oracle-proprietary jars are absent. The second command shows that the check runs against a populated directory rather than an empty one:

ls /opt/starrocks/fe/lib/ | grep -icE 'ojdbc|orai18n';
ls /opt/starrocks/fe/lib/*.jar | wc -l

0 605

The output shows zero Oracle jars out of 605 jars present.

A host firewall restricts the internal Frontend and Backend ports to the loopback interface and is reapplied on every boot. Only port 9030 is serviceable from off the VM. Inspect the rules:

sudo iptables -S STARROCKS_LOCAL | head -3

-N STARROCKS_LOCAL -A STARROCKS_LOCAL ! -i lo -p tcp -m tcp --dport 8030 -j DROP -A STARROCKS_LOCAL ! -i lo -p tcp -m tcp --dport 9020 -j DROP

Step 8 - Reach the database from your workstation

The NSG opens port 22 only, so the database is not reachable from the internet. Forward the database port over SSH:

ssh -L 9030:127.0.0.1:9030 azureuser@<vm-public-ip>

Then connect from another terminal on your workstation:

mysql -h 127.0.0.1 -P 9030 -uroot -p

To connect BI tools directly instead, add an inbound NSG rule that allows 9030/tcp from your trusted network ranges only. Never allow 0.0.0.0/0.

Sizing

The image adapts to the size of the VM you run it on. At start time, the Frontend heap is computed as 25% of total RAM (floor 1024 MiB) and the Backend memory limit as 70% of total RAM. The same image is therefore proportioned correctly on any size.

These figures were measured on a 2 vCPU / 3916 MiB build VM after a full first boot, a service restart and an 81,920-row load:

• Idle: Frontend (Java) RSS 412 MiB, Backend RSS 383 MiB, system memory used 1181 MiB
• Under query load: Frontend (Java) RSS 437 MiB, Backend RSS 412 MiB, system memory used 1234 MiB

Treat these figures as the floor, not a recommendation. They come from a trivial dataset. StarRocks is an MPP analytical engine whose working set grows with the volume of data each query scans, and upstream guidance is 16 GiB or more per node.

Standard_D4s_v5 (4 vCPU / 16 GiB) is recommended for two reasons:

• Memory. On 16 GiB, the Frontend receives a 4 GiB heap and the Backend an 11 GiB ceiling. That is real headroom for analytical scans rather than the bare minimum to start.
• CPU class. Analytical queries are sustained CPU work, which is the workload a burstable B-series VM handles worst. Burst credits deplete under continuous load, and performance collapses under exactly the queries the product exists to serve. D4s_v5 is non-burstable, so query performance stays predictable.

If your workload is light and intermittent, a burstable size runs correctly. The image is proven to boot and serve queries on 2 vCPU / 4 GiB. Size up before you put sustained analytical load on it.

Service management

Check the status of both services:

systemctl status starrocks-fe starrocks-be

Restart the cluster. Restart the Backend first, then the Frontend:

sudo systemctl restart starrocks-be
sudo systemctl restart starrocks-fe

Follow the service logs:

sudo journalctl -u starrocks-fe -f sudo journalctl -u starrocks-be -f

StarRocks also writes its own logs under /opt/starrocks/fe/log and /opt/starrocks/be/log.

Troubleshooting

Queries return no rows, or hang, although CREATE TABLE succeeded. This is the classic single-node symptom of a Frontend that is up while the Backend is not serving. The Frontend accepts connections and answers DDL on its own, so a connection test alone does not reveal the problem. Check that the Backend is alive:

mysql -h 127.0.0.1 -P 9030 -uroot -p -e "SHOW BACKENDS\G"

Read the Alive field specifically. The output contains several boolean columns, and only Alive indicates that the Backend is serving. If it is false, check systemctl status starrocks-be and the Backend log.

ERROR 1045 Access denied. Re-read the password from /root/starrocks-credentials.txt. It is unique to this VM and cannot be recovered from anywhere else.

The client cannot authenticate at all. Your client is likely MySQL 9.0 or later, which removed the mysql_native_password plugin. Use a MariaDB client or a MySQL 8.0.30+ client.

The database did not come up on the first boot. The first boot fails closed on purpose. If it cannot establish the per-VM password, it stops the database rather than leaving it reachable without one. Check sudo journalctl -u starrocks-firstboot.

Support

SecureAnyCloud provides 24/7 support with a guaranteed 24-hour response. To contact the team, email sales@secureanycloud.com.

Deploy on Azure

Launch StarRocks on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com