Setting Up Database Sharding for 1C-Bitrix

Bitrix sharding: where the database of a growing project hits the limit

While a project lives on a single database node, reads and writes share the same resources. The catalog, cart, and checkout access hot tables at the same time: row locks on stock and prices queue up, and pages wait for the buffer pool to free up.

From the outside, this looks like a slow site under load, even though the code and templates are not to blame here.

Catalog growth is the first to buckle. As long as the working set of indexes fits in memory, filters and sorting run quickly; once the volume of items and order history exceeds memory, the planner sends reads to disk — and response time grows nonlinearly.

Degradation as the catalog grows happens in steps: up to a certain size everything is even, after that sections take noticeably longer to open.

Peak load finishes the picture: replication cannot keep up with the write stream, lag grows, and some reads go to the node that is already busy with writes. Checkout breaks down right here — the transaction queues behind locks, and a retry gets a cart that is already occupied.

Database overload is not cured by optimizing individual queries if the database bottleneck is the node itself.

We look at how this is addressed: sharding in Bitrix, choosing the partition key, which tables stay on the primary node and which move to shards, and how to preserve cart and order consistency during partitioning.

What data partitioning delivers: a measurable effect for the project

Data partitioning delivers an effect that can be seen in numbers.

While the storefront, orders, and event log live in one database, peak load puts their queries in a common queue: a heavy query over order history holds locks and slows down the catalog, even though it has nothing to do with the catalog.

After moving reads to separate nodes, site response time stops depending on background jobs — the catalog is served equally fast during a sale hour and on an ordinary day.

Database fault tolerance changes qualitatively, not quantitatively. With a single node, a hardware failure stops both the storefront and order intake, and recovery time is measured in hours of restoring a backup.

When data is partitioned into segments, a failure takes down only some functions, the rest keep working, and the affected node is brought up from a replica in minutes.

A whole class of failures also goes away: disk full from the log, deadlocks on shared tables, and complete unavailability of the cart under load. The share of lost orders falls precisely because of this — the failure stops being global.

Downtime cost also becomes predictable: instead of “the site was down until someone brought it up,” there is a window of a few minutes to switch the segment. In projects on 1C-Bitrix, this is done at the data access layer level, so the application logic is not rewritten.

Bitrix sharding schemes: comparing partitioning approaches

Sharding in Bitrix is not a single scheme but a choice of attribute by which data is distributed across nodes.

The attribute determines everything else: how the application finds the right node, which queries become cross-shard, and what data consistency will have to be maintained manually. Below are four schemes that we compare at the start.

Query routing is handled either in the application — the connection is chosen based on the computed node — or by an intermediate layer that parses the query and selects the database itself. The second path requires almost no changes to business logic but limits query complexity.

Data consistency under any partitioning remains the team’s responsibility: coordination between nodes adds latency, so some operations are moved to background synchronization.

Stages of implementing a partitioned storage: from audit to handover

A partitioned storage is implemented not with a single switch but through a sequence of steps, where each next step relies on the result of the previous one.

This makes it possible to change the data schema on a running 1C-Bitrix project without stopping the business: uncertainty is removed on a copy, not on the production environment.

1. Database and workload profile audit. We collect slow queries, table sizes, and the nature of access: reads versus writes, heavy reports, catalog versus orders. The output is a data map with a rationale for what we partition and by which attribute.

2. Partitioning scheme design. We choose the sharding key, the composition of each part, and the rules for cross-partition queries and aggregates. We check that the distribution is even and does not hit a single hot part.

3. Routing setup. We define how the application routes a query to the right part, including directories that are duplicated in full. We cover the rules with tests — otherwise queries go to the wrong place and return empty result sets.

4. Validation in the test environment. We bring up a copy of the production database with comparable volume, measure response time and load distribution, and compare the result against the benchmark. We discuss switching only after that.

5. Migration without downtime. We synchronize data, enable writes to the new schema, verify integrity, and switch traffic. The degradation window is measured in minutes and does not require stopping sales.

6. Handover to support. We provide the data schema, routing rules, backup regulations, and instructions for adding new parts. Plus a metrics map that shows when partitioning has stopped coping with the load.

What the customer keeps: schemes, policies, regulations

We do not leave the customer with a working but opaque environment.

After sharding is moved to production, the team receives a documentation set that allows the scheme to be developed independently: add a node for data growth, switch a replica during a failure, and perform rebalancing without contacting us for every step.

The artifacts live in your repository and are updated by the same change as the configuration — when the sharding key changes or a node is added, the working scheme is edited, not a separate file “for reporting.”

• Topology scheme — sharding nodes, replicas, global tables, failure points, and the actual distribution of data across shards.
• Query routing map — which requests go to a specific shard, which go to the common node, and why this particular rule was chosen.
• Access policies — roles for administrators, developers, and support, separate accounts for service tasks, and permission boundaries for each shard.
• Support regulations — scheduled maintenance windows, the procedure for a node failure, and the conditions and sequence for switching a replica.
• Team instructions — step-by-step procedures for adding a shard, rebalancing, and rolling back an unsuccessful change.
• Backup regulations — the frequency of snapshots per shard, recovery verification, and copy retention periods.
• Change and metrics log — where schema edits are recorded and by which indicators degradation is visible before an incident.

Case study: how data partitioning removed degradation under load

The project is a large catalog with order history and a customer account area on 1C-Bitrix. The orders table and the line items table grew to tens of millions of rows, and during sales the product page response time went beyond 4–5 seconds.

Some queries timed out, reporting queries took minutes to run, and nightly aggregation blocked writes — managers saw outdated stock.

What we changed

We split hot tables into partitions: orders by period, line items by customer key, so that queries from the customer account and admin panel read one or two partitions instead of the entire history.

Reads were moved to replicas, writes stayed on the master node, and order history search moved to a separate denormalized structure. Cache was layered: catalog pages without personal data are assembled from composite cache, while personal blocks come from object cache.

The result

Before rollout, we ran load tests with a real peak profile. Catalog response time under load is 0.6 seconds instead of 4–5, and the share of requests that ended in an error went from 12% to zero.

Recovery after a node failure is 40 seconds instead of 15 minutes, and index rebuilds take minutes instead of hours. Nightly aggregation runs across partitions in separate transactions and no longer blocks writes.

A whole class of failures is gone — response degradation as data grows. Capacity is further increased by adding partitions, without rewriting queries or stopping the service.

How horizontal partitioning differs from replication

Replication copies the same data set to several nodes: the primary accepts writes, replicas serve reads. This offloads queries — catalog, search, customer accounts — and provides a margin for fault tolerance. But the volume on each node remains complete, and writes still go through a single node.

Horizontal partitioning cuts data into independent parts — by account, region, or date. Each shard stores its share and serves both reads and writes, so the ceiling shifts in proportion to the number of nodes.

The price is query routing, cross-shard operations, and end-to-end reports that are assembled separately.

The choice criterion is simple: if writes to a single node no longer fit into peak windows, replicas will not save you — no copy accepts writes faster than the primary. This is exactly the moment when a partitioned environment is needed.

In practice, schemes are mixed: heavy entities — orders, transaction history — are distributed across shards, and replicas are placed on each shard for reads. In 1C-Bitrix, such partitioning is usually built by sites or large accounts so that one client’s data lives on one node.

The order of work is counterintuitive: first we exhaust replicas and cache, and only then shard by a key that does not change for the entity.

Common technical doubts before data partitioning

Data partitioning affects not only server configuration but also code that has accumulated in the project over the years. Below are the questions most often asked by the customer’s engineering teams before the start, and our answers to each.

What about the integrity of accumulated data?

Before partitioning, we calculate checksums by table and verify them after migration — by rows, relationships, and counters. A discrepancy in a single table means returning to the original scheme, not tweaking a live database.

Will customizations and backward compatibility break?

We move routing keys into a separate layer so that code accesses data through familiar interfaces. We check custom modules and agents separately: some write directly to tables bypassing the layer — we rewrite such places before migration.

How does backup change?

Backup becomes segment-by-segment: we take a consistent snapshot of each node and verify recovery in the test environment, not just the fact that a copy was created. Rollback remains predictable, and recovery time does not grow with database volume.

Let’s discuss the task: what is needed to estimate data partitioning

Estimating data partitioning is not done “by eye”: sharding has no universal scheme — the partition key is chosen for the catalog structure and workload profile.

Provide the inputs from the list below, and we will come back with a work estimate, a sharding scheme, and an implementation plan with migration windows.

• database volume and the largest tables: where orders, products, event logs, and statistics are concentrated;
• workload profile: the share of reads and writes, peak intervals, which reports and exports load the environment;
• the partition key that is closer to your business meaning: by client, by project, by region, or by record creation date;
• the current fault-tolerance scheme: master, replicas, replication, backup, and how recovery was last performed;
• modules and customized components that access the database directly, including exchanges with 1C;
• the acceptable downtime window and rollback requirements: how quickly the unified environment must be restored;
• access and a test bench where a migration rehearsal can be run without risk to the production environment.

We will propose the order of work ourselves: analysis of queries and plans, key selection, migration rehearsal on a copy, phased switching of nodes, and post-launch monitoring.

Describe the task and attach the inputs — we will discuss it substantively and come back with an estimate and a plan.