http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> I'm trying to use Hybrid row-column...
# questions-and-troubleshooting
t
@Rocky I'm trying to use Hybrid row-column storage but got error: 
SQL Error [1064] [42000]: Unknown properties: {store_type=column_with_row}
This is my configuration
Copy code
mysql> SELECT current_version();
+-------------------+
| current_version() |
+-------------------+
| 4.0.8-2090bfc     |
+-------------------+
1 row in set (0.02 sec)

mysql> ADMIN SHOW FRONTEND CONFIG LIKE "enable_experimental_rowstore";
+------------------------------+------------+-------+---------+-----------+---------+
| Key                          | AliasNames | Value | Type    | IsMutable | Comment |
+------------------------------+------------+-------+---------+-----------+---------+
| enable_experimental_rowstore | []         | true  | boolean | true      |         |
+------------------------------+------------+-------+---------+-----------+---------+
1 row in set (0.01 sec)

mysql> SHOW COMPUTE NODES;
Empty set (0.01 sec)

mysql> SHOW BACKENDS;
+-----------+------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+-----------+------------------+---------------+---------------+---------+----------------+--------+---------------+--------------------------------------------------------+-------------------+-------------+----------+----------+-------------------+------------+------------+--------------------------------------------------------+----------+------------+
| BackendId | IP         | HeartbeatPort | BePort | HttpPort | BrpcPort | LastStartTime       | LastHeartbeat       | Alive | SystemDecommissioned | ClusterDecommissioned | TabletNum | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | MaxDiskUsedPct | ErrMsg | Version       | Status                                                 | DataTotalCapacity | DataUsedPct | CpuCores | MemLimit | NumRunningQueries | MemUsedPct | CpuUsedPct | DataCacheMetrics                                       | Location | StatusCode |
+-----------+------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+-----------+------------------+---------------+---------------+---------+----------------+--------+---------------+--------------------------------------------------------+-------------------+-------------+----------+----------+-------------------+------------+------------+--------------------------------------------------------+----------+------------+
| 10002     | 10.23.4.28 | 9050          | 9060   | 8040     | 8060     | 2026-05-05 14:10:02 | 2026-05-15 10:25:42 | true  | false                | false                 | 934       | 9.156 GB         | 1019.124 GB   | 1.020 TB      | 2.47 %  | 2.47 %         |        | 4.0.8-2090bfc | {"lastSuccessReportTabletsTime":"2026-05-15 10:25:38"} | 1.004 TB          | 0.89 %      | 16       | 25.321GB | 0                 | 23.47 %    | 0.0 %      | Status: Normal, DiskUsage: 0B/800GB, MemUsage: 5GB/5GB |          | OK         |
| 10270     | 10.23.4.29 | 9050          | 9060   | 8040     | 8060     | 2026-05-05 14:11:32 | 2026-05-15 10:25:42 | true  | false                | false                 | 933       | 9.115 GB         | 1019.976 GB   | 1.020 TB      | 2.39 %  | 2.39 %         |        | 4.0.8-2090bfc | {"lastSuccessReportTabletsTime":"2026-05-15 10:25:38"} | 1.005 TB          | 0.89 %      | 16       | 25.321GB | 0                 | 23.41 %    | 0.0 %      | Status: Normal, DiskUsage: 0B/800GB, MemUsage: 5GB/5GB |          | OK         |
| 10381     | 10.23.4.30 | 9050          | 9060   | 8040     | 8060     | 2026-05-05 14:13:02 | 2026-05-15 10:25:42 | true  | false                | false                 | 935       | 9.192 GB         | 1020.469 GB   | 1.020 TB      | 2.34 %  | 2.34 %         |        | 4.0.8-2090bfc | {"lastSuccessReportTabletsTime":"2026-05-15 10:25:38"} | 1.006 TB          | 0.89 %      | 16       | 25.321GB | 0                 | 23.34 %    | 0.0 %      | Status: Normal, DiskUsage: 0B/800GB, MemUsage: 5GB/5GB |          | OK         |
+-----------+------------+---------------+--------+----------+----------+---------------------+---------------------+-------+----------------------+-----------------------+-----------+------------------+---------------+---------------+---------+----------------+--------+---------------+--------------------------------------------------------+-------------------+-------------+----------+----------+-------------------+------------+------------+--------------------------------------------------------+----------+------------+
3 rows in set (0.01 sec)
When running the example code:
Copy code
CREATE TABLE users (
  id bigint not null,
  country string,
  city string,
  revenue bigint
)
PRIMARY KEY (id)
DISTRIBUTED by HASH (id)
PROPERTIES ("store_type" = "column_with_row");
I got 
SQL Error [1064] [42000]: Unknown properties: {store_type=column_with_row}
cc @Quoc Khanh
r
The error 
SQL Error [1064] [42000]: Unknown properties: {store_type=column_with_row}
typically occurs because the Hybrid row-column storage feature is currently only supported in shared-nothing (classic) StarRocks clusters. Based on your 
SHOW BACKENDS
output, your cluster appears to be a shared-data (cloud-native) architecture. The presence of the 
DataCacheMetrics
column in the backends list is a clear indicator of the shared-data architecture, which uses a local disk cache to accelerate access to remote storage (like S3 or HDFS). Why it failed: * Architectural Limitation: As of the current official documentation, StarRocks shared-data clusters do not support hybrid row-column storage. Even if 
enable_experimental_rowstore
is set to 
true
on the FE, the property 
store_type
will be rejected as unknown because the cloud-native storage engine does not yet support the underlying 
__row
column format required for this feature. * Version Note: While you are running version 
4.0.8-2090bfc
(which appears to be a development or future-dated version), the feature gap for hybrid storage in shared-data clusters remains the most likely cause for this specific property error. Recommendations: 1. Verify Cluster Type: Confirm if your cluster is indeed shared-data (Cloud Native). Shared-data clusters store data on remote object storage (S3/OSS/HDFS) rather than local BE disks. 2. Use Shared-nothing: If you require Hybrid row-column storage for high-concurrency point queries or prepared statements, you must currently use a shared-nothing StarRocks cluster. 3. Alternative for Point Queries: If you cannot switch architectures, ensure your Primary Key tables are optimized. While not "hybrid," Primary Key tables in shared-data clusters still support high-performance point lookups, though they won't benefit from the specific row-store optimizations like "short-circuit" reading of the entire row. For more details, you can refer to the Feature Support for Shared-data Clusters and Hybrid row-column storage limits in the official documentation. References • deployment/shared_data/feature-support-shared-data.md • table_design/hybrid_table.md
t
@Rocky how can I change to shared-nothing
r
To change from a shared-data (cloud-native) cluster to a shared-nothing (classic) cluster, you cannot simply flip a configuration switch. Because the two architectures use different storage engines and data formats, you must deploy a new shared-nothing cluster and migrate your data. 1. Deployment Changes To set up a shared-nothing cluster, you need to modify the configuration of your nodes: * FE Configuration (
fe.conf
): Ensure 
run_mode
is set to 
shared_nothing
(which is the default if the parameter is omitted).
Copy code
properties
    # Remove or comment out the shared_data setting
    # run_mode = shared_data
* Backend Nodes: In shared-nothing, you use Backends (BE) instead of Compute Nodes (CN). While the binary is often the same, BEs are configured to manage local storage for data persistence and replicas. Ensure your BEs have sufficient local disk space for the data and its replicas (default is 3 replicas). 2. Data Migration Since the "Cross-cluster Data Migration Tool" and the standard 
BACKUP/RESTORE
commands do not currently support migrating out of shared-data into shared-nothing, you should use one of the following manual methods: Method A: INSERT INTO ... SELECT (Recommended) If your new cluster can access the network of the old one: 1. In your new shared-nothing cluster, create a StarRocks External Catalog pointing to the shared-data cluster. 2. Create the destination tables in the new cluster (now you can include 
PROPERTIES ("store_type" = "column_with_row")
). 3. Run the migration:
Copy code
sql
    INSERT INTO target_db.users
    SELECT * FROM shared_data_catalog.source_db.users;
Method B: Export and Load 1. Export: Use the 
EXPORT
command in the shared-data cluster to dump your tables to a shared object store (S3, HDFS, etc.) in Parquet or CSV format. 2. Load: Use 
Broker Load
or 
Routine Load
in the new shared-nothing cluster to ingest that data into your new tables. Why this is required * Storage Location: Shared-data stores data on remote object storage; shared-nothing stores data on local BE disks. * Metadata: The FE manages metadata differently in these modes (e.g., tablet distribution and replication logic). * Feature Support: As noted previously, "Hybrid row-column storage" relies on the local storage engine's ability to handle the hidden 
__row
column, which is currently a shared-nothing exclusive feature. References • deployment/shared_data/feature-support-shared-data.md • administration/export.md • data_source/catalog/starrocks_catalog.md References • deployment/shared_data/feature-support-shared-data.md • faq/shared_data_faq.md • administration/cluster_snapshot.md • deployment/shared_data/minio.md • deployment/shared_data/gcs.md • deployment/shared_data/azure.md
t
@Rocky How can we check the mode after config 
run_mode = shared_nothing
r
To verify that your cluster is running in shared-nothing mode after changing the configuration, you can use the following methods: 1. Check FE Configuration The most direct way to see what mode the Frontend (FE) has loaded is to query the configuration directly:
Copy code
sql
ADMIN SHOW FRONTEND CONFIG LIKE "run_mode";
* Shared-nothing: Returns 
shared_nothing
. * Shared-data: Returns 
shared_data
. 2. Check Node Types In StarRocks, the terminology and management commands differ between the two modes: * Shared-nothing: Uses Backends. Run 
SHOW BACKENDS;
. You should see your nodes listed here with columns like 
TabletNum
and 
DataUsedCapacity
representing local disk usage. * Shared-data: Uses Compute Nodes. Run 
SHOW COMPUTE NODES;
. In shared-nothing mode, this command will typically return an empty set unless you have explicitly added stateless compute nodes. 3. Check Table Metadata If you have created tables, you can check their internal storage type. Shared-nothing tables are of type 
OLAP
, whereas shared-data tables are 
CLOUD_NATIVE
. 1. Find your Database ID: 
SHOW PROC '/dbs';
2. Check the tables in that DB: 
SHOW PROC '/dbs/<db_id>';
3. Look at the Type column. It should say OLAP for shared-nothing. ⚠️ Important Reminder As mentioned in the previous response, you cannot simply change 
run_mode
on an existing cluster. * If you change 
run_mode
in 
fe.conf
and restart an existing shared-data FE, it will likely fail to start or encounter metadata inconsistencies because the underlying storage format in the metadata (BDBJE) and the data on the backends are incompatible. * To "change" to shared-nothing, you must format/clear the metadata directory of your FE and the storage directories of your BEs, essentially starting a fresh cluster. References • administration/management/FE_configuration.md • deployment/deploy_manually.md • deployment/shared_data/minio.md References • administration/management/FE_configuration.md • deployment/deploy_manually.md • deployment/shared_data/minio.md • deployment/shared_data/s3.md • knowledge/admin_and_operation/shared_data_compaction.md
t
@Rocky The cluster show shared_nothing mode:
Copy code
mysql> ADMIN SHOW FRONTEND CONFIG LIKE "run_mode";
+----------+------------+----------------+--------+-----------+---------+
| Key      | AliasNames | Value          | Type   | IsMutable | Comment |
+----------+------------+----------------+--------+-----------+---------+
| run_mode | []         | shared_nothing | String | false     |         |
+----------+------------+----------------+--------+-----------+---------+
but the create table still error:
Copy code
mysql> CREATE TABLE default_catalog.cdp_customer_profile.users (
    ->   id bigint not null,
    ->   country string,
    ->   city string,
    ->   revenue bigint
    -> )
    -> PRIMARY KEY (id)
    -> DISTRIBUTED by HASH (id)
    -> PROPERTIES ("store_type" = "column_with_row");
ERROR 1064 (HY000): Unknown properties: {store_type=column_with_row}
r
Based on the error message and your current setup in version 
4.0.8
, the most likely reason for the 
Unknown properties
error—despite being in 
shared_nothing
mode—is that the 
enable_experimental_rowstore
configuration is no longer active. 1. Check for Config Persistence In StarRocks, when you use 
ADMIN SET FRONTEND CONFIG
, the change is often not persistent across restarts unless you also add it to your 
fe.conf
file. Since you recently changed the 
run_mode
(which requires an FE restart), it is highly probable that 
enable_experimental_rowstore
reverted to its default value of 
false
. Run this command to verify its current state:
Copy code
sql
ADMIN SHOW FRONTEND CONFIG LIKE "enable_experimental_rowstore";
If the value is 
false
, the FE parser will not recognize the 
store_type
property and will throw the 
Unknown properties
error. Fix: Set it again and, more importantly, add it to your 
fe.conf
 on all FE nodes to ensure it survives restarts:
Copy code
sql
ADMIN SET FRONTEND CONFIG ("enable_experimental_rowstore" = "true");
2. Verify Table Model and Property Case Although StarRocks properties are generally case-insensitive, try using the uppercase version to match the official documentation exactly:
Copy code
sql
PROPERTIES ("STORE_TYPE" = "column_with_row");
Also, ensure that your Primary Key definition and the 
PROPERTIES
block are part of the same 
CREATE TABLE
statement (which your snippet shows is correct). 3. StarRocks 4.0 Specifics You are running a 4.0.x release (which, as of early 2026, includes several architectural refinements). In some recent builds, property validation has become stricter: * Storage Type: Ensure the 
storage_engine
is set to 
olap
(which is the default). * Internal Catalog: You are creating the table in 
default_catalog
. Confirm that the database 
cdp_customer_profile
was created locally and is not an external database (like one mapped from a Glue or Hive catalog), as hybrid storage is only supported for local StarRocks tables. Summary Checklist 1. Re-enable: 
ADMIN SET FRONTEND CONFIG ("enable_experimental_rowstore" = "true");
2. Verify Mode: Ensure 
ADMIN SHOW FRONTEND CONFIG LIKE "run_mode"
still shows 
shared_nothing
. 3. Check Backends: Run 
SHOW BACKENDS;
and ensure the 
Alive
column is 
true
for all nodes. If the FE thinks it is in shared-nothing but the BEs are not correctly registered, some schema validation paths may fail. If the error persists after re-enabling the config, it is possible that in your specific build of 4.0.8, this property name has been updated to 
storage_type
. You can try: 
PROPERTIES ("storage_type" = "column_with_row")
row")` as a fallback.")` (fallback test).` References • table_design/hybrid_table.md • administration/management/FE_configuration.md • release_notes/release-3.2.md References • best_practices/primarykey_table.md • table_design/table_types/primary_key_table.md • best_practices/query_tuning/schema_tuning.md • sql-reference/information_schema/tables_config.md • table_design/table_types/table_types.md
t
@Rocky the config've already been 
true
Copy code
mysql> ADMIN SHOW FRONTEND CONFIG LIKE "enable_experimental_rowstore";
+------------------------------+------------+-------+---------+-----------+---------+
| Key                          | AliasNames | Value | Type    | IsMutable | Comment |
+------------------------------+------------+-------+---------+-----------+---------+
| enable_experimental_rowstore | []         | true  | boolean | true      |         |
+------------------------------+------------+-------+---------+-----------+---------+
1 row in set (0.01 sec)
@Kevin Cai Hi can you help me with this problem
r
The 
Unknown properties: {store_type=column_with_row}
error indicates that the StarRocks Frontend (FE) does not recognize 
store_type
as a valid property for the table you are creating. Since you have already verified that 
run_mode = shared_nothing
and 
enable_experimental_rowstore = true
, the problem likely stems from one of the following issues: 1. Property Name Variation In some recent versions (including some builds of 4.0.x and specific distributions), the property name has been updated or requires a specific alias. Try using 
storage_type
 instead of `store_type`:
Copy code
sql
PROPERTIES ("storage_type" = "column_with_row");
2. FE Configuration Sync/Restart While 
enable_experimental_rowstore
is marked as mutable (
IsMutable = true
), some versions require the property to be present in the 
fe.conf
 file at startup to properly register the property keys in the table creator's whitelist. * Add 
enable_experimental_rowstore = true
to your 
fe.conf
. * Restart the FE Leader node. * If you have multiple FEs, ensure all of them have this config and have been restarted. 3. Metadata "Ghost" State If this cluster was originally deployed in 
shared_data
mode and you switched to 
shared_nothing
by only changing the config file: * The FE metadata (stored in the 
meta/
directory) may still contain internal flags identifying the cluster as cloud-native. Hybrid row-column storage is strictly disabled for cloud-native clusters. * Verification: Run 
SHOW FRONTENDS;
and check if the nodes are correctly identified. Also, check 
SHOW BACKENDS;
. If you see "Compute Nodes" instead of "Backends," the cluster is still behaving like a shared-data cluster. * Fix: To truly switch modes, you must stop the cluster, clear the FE metadata directory and the BE storage directories, and then start fresh in shared-nothing mode. (Note: This will delete all existing data in that cluster). 4. Database Context Ensure the database was created after the cluster was in shared-nothing mode. If you are using a database that existed while the cluster was in 
shared_data
mode, try creating a brand new database and then creating the table inside it:
Copy code
sql
CREATE DATABASE test_rowstore;
USE test_rowstore;
CREATE TABLE users (...) PRIMARY KEY (id) ...;
Summary of what to try next: 1. Try 
PROPERTIES ("storage_type" = "column_with_row")
. 2. Try 
PROPERTIES ("STORE_TYPE" = "column_with_row")
(all caps). 3. Confirm that 
SHOW BACKENDS;
returns your nodes (and not 
SHOW COMPUTE NODES;
). 4. If it still fails, add the config to 
fe.conf
and restart the FE. References • table_design/hybrid_table.md • administration/management/FE_configuration.md • faq/shared_data_faq.md References • administration/management/FE_configuration.md • administration/management/BE_configuration.md
Open in Slack
PreviousNext
Powered by