Optimizing 1C-Bitrix Performance with Database Sharding
Partitioning splits a table within one server. Sharding distributes data across multiple database servers. When a single MySQL server cannot handle the load (100% CPU, disk I/O bottleneck), horizontal scaling via sharding is an option. For Bitrix, this is a non-trivial task because the core is designed to work with one database. According to the Bitrix Cluster Module Documentation, the built-in cluster module supports master-slave and module-level separation but not full sharding. Our team, with 7+ years of Bitrix experience, has completed over 100 high-load projects. We have 30+ certified specialists and a 98% client satisfaction rate.
When Is Sharding Needed?
If after configuring caching (Redis, tagged cache), enabling composite mode, and setting up master-slave replication the database still hits CPU limits, it's time to consider sharding. On one project with a catalog of 2 million products, complex queries took 30 seconds without sharding. After offloading the statistics and search modules to separate servers, the time dropped to 300 ms — a 99% improvement for those queries. In another case, we reduced database CPU usage from 95% to 40% within a week.
Built-in Mechanism: the cluster Module
Bitrix provides the cluster module (available in Business and Enterprise editions). It supports:
- Master-slave replication — writes to master, reads from one or more slaves. Not pure sharding, but relieves read load.
-
Moving modules to a separate database — a specific module (e.g.,
searchorstatistic) can use its own database on another server.
Configuring master-slave via cluster:
- Set up MySQL/MariaDB replication using standard methods (GTID or positional).
- In the Bitrix admin panel: Settings → Web Cluster → Databases → Add.
- Provide the slave server parameters: host, port, login, password.
- Bitrix automatically routes SELECT queries to the slave, and INSERT/UPDATE/DELETE to the master.
The module monitors replication lag (Seconds_Behind_Master) and switches reads back to the master if the threshold is exceeded.
Module-Level Sharding
The cluster module allows moving tables of a specific module to a separate database server. In practice:
-
statisticmodule — tablesb_stat_*generate 80% of INSERT load on a typical site. Moving them offloads the main database. -
searchmodule — tablesb_search_*are heavy for full-text search. An alternative is to offload search to Elasticsearch. -
forum/blogmodule — if the forum or blog is active, their tables can be isolated.
Configuration: Web Cluster → Databases → [server] → Modules — select the module to move. Bitrix redirects queries to that module's tables to the specified server.
Horizontal Data Sharding
Full sharding — splitting one table by a key (e.g., products with IDs 1–100000 on server A, 100001–200000 on server B) — is not supported out of the box by Bitrix. The D7 ORM and the legacy API work with a single database connection.
Implementation is possible but requires:
- A proxy layer — Vitess or ProxySQL routes queries according to sharding rules transparently to the application.
- A custom DB class — inheriting from
Bitrix\Main\DB\MysqliConnectionwith routing logic. - Limitations: JOINs across shards are impossible, aggregate queries must be collected in the application.
In practice, full horizontal sharding for Bitrix is rarely used. More common is a combination: master-slave + offloading heavy modules + caching.
Comparison of Sharding Methods
| Method | Complexity | Impact on Load | Bitrix Support |
|---|---|---|---|
| Partitioning | Low | Moderate (query speedup) | Partial (via MySQL) |
| Master-slave | Medium | Read: ×3–×5 | Full (cluster module) |
| Module offloading | Medium | Master load: –40% | Full (cluster module) |
| Horizontal sharding | High | Radical | None (custom code) |
Impact of Sharding on Architecture
Sharding requires changing query logic: JOINs only within a shard, aggregates via UNION, transaction support only at the shard level. If sharding is implemented via a proxy layer, the application does not change, but the proxy handles routing and can become a bottleneck. Our experience: Vitess is better than ProxySQL for Bitrix because it supports automatic shard rebalancing.
Process of Setup
- Audit the current database architecture, measure load, analyze slow query logs.
- Choose a topology: master-slave, module offloading, or sharding.
- Configure replication and monitoring (lag < 1 sec).
- Move modules to separate servers, conduct load testing.
- If full sharding is needed, install a proxy, migrate data.
- Optimize caching: Redis, tagged cache, composite mode.
Timelines — from 2 weeks for master-slave to 2 months for full sharding. Typical cost ranges from $5,000 to $20,000 depending on complexity. Clients typically save 30-50% compared to upgrading all hardware.
What's Included in the Work
We provide:
- Architecture diagram with data location.
- Configuration files for MySQL/MariaDB, ProxySQL/Vitess.
- Scripts for monitoring lag and integrity.
- Documentation for disaster recovery procedures.
- Training for administrators and developers.
- Guarantee of stable operation — 30 days of 24/7 support after launch.
Contact us for an assessment of your project. Our team: 7+ years of Bitrix experience, 100+ high-load projects, 30+ certified specialists, 98% client satisfaction rate. Get a consultation on sharding — reach out, and we'll estimate the scope of work.