Lakehouse analytics

Lakehouse analytics at storage economics

Name: StarRocks Lakehouse Hosting on S3-Compatible Storage
Brand: Seemi Cloud

Deploy StarRocks frontend and compute-node containers for shared-data analytics, keep durable data on S3-compatible object storage, and connect through familiar SQL clients and BI tools.

Deploy!Estimate cost Docs

SEEMI CLOUD

Reliable infrastructure with operational safeguards built in

Secure by design Backup ready Regional choice API and agent ready

One lakehouseUnify analytical data access

Fast SQLInteractive and high-concurrency analytics

Open storageUse S3-compatible object storage

Elastic computeScale query resources separately

Capabilities

A practical platform for centralized analytics

Cost-efficient lakehouse storage

Keep large analytical datasets on compatible object storage while scaling compute separately for query demand.

Frontend and compute topology

Use FE containers for metadata and planning, with CN containers for shared-data query execution.

Familiar SQL access

Connect using supported MySQL clients, drivers, DbGate, and business-intelligence tools.

Granular authorization

Use StarRocks users, roles, and privileges to control access to catalogs, databases, tables, and supported operations.

Storage freedom

Seemi object storage provides an integrated path, while compatible external object-storage providers can also be used.

Enterprise data engineering

Seemi can assist with migration, ingestion pipelines, topology design, and multi-region architecture.

Use cases

Built for real workloads

Choose a supported service from the catalog or bring a workload that fits your architecture.

Centralized enterprise analytics

Large analytical datasets

Lakehouse queries over object storage

Real-time and ad hoc analysis

BI tools requiring SQL access

Enterprise ingestion and migration projects

Enterprise lakehouse impact

Unify data and simplify analytical delivery

A centralized lakehouse can reduce duplicated pipelines, make governed data available to more teams, and support reporting, operational analytics, and AI-oriented query workloads from a shared analytical foundation. StarRocks is used in large-scale analytical environments at organizations including Tencent and Lenovo.

Ready to move forward?

Deploy with confidence, or talk to an engineer first.

Review pricing, browse the live catalog, or contact Seemi Cloud for migration and enterprise engineering support.

Browse catalog Estimate your cost Talk to us

SERVICE AT A GLANCE

Key technical and operational facts

Concise deployment facts for evaluation. The portal configuration and applicable SKU description remain authoritative.

Architecture: Shared-data analytical database
Frontend role: FE for metadata, SQL, planning, and scheduling
Compute role: CN for execution, ingestion, and local cache
Query protocol: MySQL-compatible interface, commonly 9030/TCP
Durable data: S3-compatible or another supported object store
Metadata: Persistent FE metadata requires explicit protection
Scale model: Compute can scale independently from object data
Engineering: Optional topology, ingestion, migration, and tuning services

FREQUENTLY ASKED QUESTIONS

Practical answers before deployment

Understand connectivity, backups, limitations, and operating responsibilities before selecting a SKU.

What is StarRocks shared-data mode?

Shared-data mode separates durable object storage from compute. FE nodes manage metadata and planning, while CNs execute queries and cache hot data locally.

Does StarRocks use an Iceberg lakehouse underneath every table?

No. StarRocks shared-data tables use StarRocks storage and metadata behavior unless an external catalog or lakehouse integration is explicitly configured.

Which ports does StarRocks use?

Common FE ports include 9030 for the MySQL-compatible query interface, 8030 for HTTP, 9020 for RPC, and 9010 for edit-log coordination. Internal ports should remain restricted.

Can clients use MySQL tools?

Compatible MySQL clients and drivers can connect to the FE query interface. Protocol compatibility does not make StarRocks a transactional MySQL database; SQL semantics and storage behavior differ.

Is one FE and one CN highly available?

No. That is a compact development topology. Production resilience can require multiple FEs, multiple CNs, durable object storage, and an explicitly designed recovery architecture.

What must be backed up?

A complete recovery strategy must protect FE metadata, durable object data, security configuration, external catalog state, and the ability to replay or reconstruct ingestion. CN cache alone is not a backup.

CONTINUE EXPLORING