Is your feature request related to a problem?
Yes.
When using ShardingSphere-Proxy for time-based sharding (for example, monthly sharding), the proxy can route SQL according to sharding rules, but the target physical table must already exist.
In practice, this causes several problems:
- future shard tables need to be created in advance
- write traffic fails immediately if a routed physical table is missing
- shard table lifecycle management has to be handled outside ShardingSphere-Proxy
- AutoTable helps simplify rule configuration, but it does not solve physical table creation
For Proxy users, especially in time-based sharding scenarios, this increases operational complexity.
Describe the feature you would like
I would like ShardingSphere-Proxy to provide an optional extension mechanism for shard table lifecycle management.
Possible directions may include:
-
Template-based table creation
- allow users to specify a template table or template DDL
- when a routed target table is missing, an extension point could decide whether and how to create it
-
Managed pre-creation support
- support pre-creating future shard tables for predictable time-based sharding scenarios
- for example, create the next N monthly tables in advance
-
DistSQL-oriented management
- provide a managed way to configure shard table lifecycle behavior through DistSQL
- including scope, safety constraints, naming pattern validation, and idempotency requirements
Describe the benefits of this feature
- reduce operational burden for time-based sharding
- avoid write failures caused by missing future shard tables
- make Proxy easier to use in dynamic shard expansion scenarios
- provide a more complete solution around shard lifecycle management
Describe alternatives you have considered
Current alternatives are all external to ShardingSphere-Proxy, for example:
- manually pre-creating future physical tables
- using scheduled jobs to create tables periodically
- letting the application detect missing tables and execute DDL before retrying writes
These approaches work, but they move shard lifecycle management outside the proxy layer.
Additional context
I understand that current ShardingSphere behavior focuses on rule configuration and SQL routing, and that physical table creation is not automatically handled today.
This request is not a bug report. It is a feature proposal to ask whether the community would consider providing an official extension mechanism or managed capability for shard table lifecycle management in ShardingSphere-Proxy.
Is your feature request related to a problem?
Yes.
When using ShardingSphere-Proxy for time-based sharding (for example, monthly sharding), the proxy can route SQL according to sharding rules, but the target physical table must already exist.
In practice, this causes several problems:
For Proxy users, especially in time-based sharding scenarios, this increases operational complexity.
Describe the feature you would like
I would like ShardingSphere-Proxy to provide an optional extension mechanism for shard table lifecycle management.
Possible directions may include:
Template-based table creation
Managed pre-creation support
DistSQL-oriented management
Describe the benefits of this feature
Describe alternatives you have considered
Current alternatives are all external to ShardingSphere-Proxy, for example:
These approaches work, but they move shard lifecycle management outside the proxy layer.
Additional context
I understand that current ShardingSphere behavior focuses on rule configuration and SQL routing, and that physical table creation is not automatically handled today.
This request is not a bug report. It is a feature proposal to ask whether the community would consider providing an official extension mechanism or managed capability for shard table lifecycle management in ShardingSphere-Proxy.