What is database sharding?

To build high-performing applications — especially those leveraging AI or serving millions of users — engineering leaders must ensure their systems can scale efficiently without compromising reliability or speed. Database sharding (distributing data horizontally across multiple servers) is often thought of as a solution. However, it introduces operational challenges, increases complexity in deployments, maintenance, and queries.

Before adopting sharding, it’s important to consider performance-boosting alternatives that are cheaper and faster to implement. These benefits are crucial for technical decision-makers and CTOs who must balance long-term scalability with short-term development velocity and operational simplicity.

At Lazer, we’ve helped numerous clients dramatically improve database performance and eliminate bottlenecks — without jumping straight to sharding.

Through targeted, low-overhead strategies, we’ve delivered faster results while keeping systems simple and maintainable.

These solutions strike the right balance between long-term scalability and short-term development velocity — exactly what today’s CTOs and technical leaders need.

Let's walk though 8 strategies we've used and how to implement them in your own database.

Denormalization

When learning SQL we’re taught to normalize databases — splitting data into logical tables to avoid data redundancy and ensure consistency. But sometimes, breaking the rules helps: denormalization is a valid way to speed up complex queries by reducing joins.

A rule of thumb is lean toward normalization if you want to speed up write-heavy queries and use denormalization for read-heavy queries. In the following example, we denormalize and repeat user data in the orders table to avoid doing an extra join lookup on the users table.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER, /* Denormalized from users table */
  user_name TEXT,  /* Denormalized from users table */
  product TEXT,
  amount DECIMAL
);

• When to use it: Good for read-heavy workloads with expensive joins.
• Tradeoffs: Denormalization increases the number of update paths — changes to user data now must be updated in multiple places. This can lead to inconsistencies if not managed carefully.‍
• When to stop: If you're spending more time syncing denormalized data or debugging consistency issues than you are speeding up reads, it's time to rethink denormalizing.

Indexing

Creating indexes is one of the best way to improve query performance as it avoids full table scans. Database indexes function the same as a book index: when we need to find something in a book, we can use the index to quickly find the page that contains the information we want to read.

Imagine we have a table with all the purchases made by users of a commerce website. It could have millions of rows containing every purchase made by past users.

CREATE TABLE purchases (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    amount NUMERIC(10, 2) NOT NULL,
    purchased_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Now we want to find the users who purchased products in the last month.

If we try to do such a query without any index, the database would need to do a full table scan, scanning row by row to get the answer. If we use an index,we can avoid the full table scan and quickly find users who purchased something in the last month.

CREATE INDEX index_purchased_at
	ON purchases (purchased_at, user_id);

Tradeoffs: Indexes increase write overhead and consume disk space. Over-indexing can slow down insert/update operations and bloat your database.

Tip: Prioritize indexing for frequently queried fields, and monitor usage with tools like pg_stat_user_indexes in Postgresql, or db.myCollection.aggregate([{ $indexStats: {} }]) in MongoDB.

Index-only scans or covered queries

Another strategy is the index-only scan in PostgreSQL, or covered queries in MongoDB. When a query can be satisfied entirely by using an index, the query planner can avoid the extra trip into the table heap and just extract the information directly from the index, acting effectively as a cache. In this case we can get blazing fast queries.

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT,
    email TEXT,
);

/* Create an index covering all columns needed by the query */
CREATE INDEX idx_users_session ON users (id, name, email);

With the above index we can cover typical queries, such as session queries, without having to rely on a memory database.

Design patterns

We can use data design patterns to help us organize and speed up the performance of our queries. Some examples are:

• Archive pattern: If our queries mainly involve the most recent or newer items, we can move older data into a different table or storage. Examples include just keeping comments posted by users in the last 6 months, or the financial data from the last year, and moving everything else into an archive.
• Attribute pattern: This involves grouping similar fields into a sub-document or array. It’s particularly useful when dealing with documents containing many fields, but only a subset are frequently queried (e.g., product specifications with varying attributes). By organizing data this way, you can reduce the number of required indexes.
  
  • Imagine we have an commerce storefront focusing on video games, where each game can have multiple attributes . We can nest all the attributes under an array and index it. This allows us to avoid having one index per attribute, speeding up index creation and maintenance.

{
  "_id": "123",
  "name": "Mario Bros",
  "price": 1500,
  // nest attributes in an array which will be indexed
	"attributes": [
	  { "key": "category", "value": "family" },
	  { "key": "platform", "value": "Nintendo Switch" },
	  { "key": "multiplayer", "value": true },
	  { "key": "age_rating", "value": "E (Everyone)" },
	  { "key": "developer", "value": "Nintendo" },
	  { "key": "release_year", "value": 1983 },
	  { "key": "genre", "value": "Platformer" }
		]
}

• Computed pattern: Instead of calculating resource-intensive values during read operations, this pattern stores pre-computed results in the document (e.g., total order value or total sales in a month). The data is updated only when needed, shifting computational overhead away from reads.