DEV Community: Sunny Badgujar

How Long Does It Take to Build a Shopify Store?

Sunny Badgujar — Thu, 17 Sep 2026 17:09:31 +0000

Originally published at sunnybadgujar.com.

"How long will my Shopify store take?" is usually the second question after "what will it cost?" — and it has the same honest answer: anywhere from a few days to a few months, depending on choices you've probably not made yet. But unlike cost, the timeline has one dominant variable most people don't expect. It isn't the code. It's how ready you are. Here's a realistic breakdown of where the time actually goes.

The reason "how long does a Shopify store take" gets such a vague answer is the same reason the cost question does: "a store" describes two very different jobs. Setting up a good theme, loading a tidy set of products and launching is genuinely a matter of days. Designing a bespoke storefront, migrating years of data from another platform and wiring the store into your warehouse and accounting is a matter of months. Both are "building a Shopify store," and the gap between them is enormous.

So rather than promise a number that would be wrong for most people reading it, let's walk through what sets the timeline — the build type, the phases a real project moves through, and the levers that stretch it. If you're weighing time against budget, it's worth reading this alongside what a Shopify store costs to build, because the same choices drive both.

The biggest factor: theme, customised theme, or fully custom

Just like cost, the timeline is decided first by how much of the store is bespoke. Here's the honest range for each level — assuming your content is ready, which, as you'll see, is a big assumption:

Build type	What's involved	Realistic timeline
Theme, set up well	A quality theme configured to your brand, a small–medium catalog loaded, launched	A few days to ~2 weeks
Customised theme	A theme reshaped to your brand — custom sections, a few custom features, a product migration	~3 to 8 weeks
Fully custom / headless	A bespoke storefront or headless build with complex features and integrations	A few months+

The most common case: a good theme, customised where it matters, landing in the three-to-eight-week band. Most stores don't need — and shouldn't wait for — a fully custom build. If someone's promising you a bespoke, integrated store in a week, something in that promise isn't real.

Where the weeks actually go: the phases of a build

A store doesn't get built in one block of "development." It moves through phases, and each one takes real time — including time that's on your side of the table, not the developer's. For a typical customised-theme store, here's roughly how the weeks break down.

1. Discovery and planning — a few days to a week

Before anything is designed, the build needs a clear brief: what you sell, how you sell it, which features are must-have, what it integrates with, and what's explicitly out of scope. This phase feels like it isn't "building," but skipping it is the single most reliable way to blow the timeline later — every decision deferred here comes back as rework halfway through. The faster you can answer these questions, the sooner the clock starts on real work.

2. Design — one to two weeks

If you're customising a theme, this is choosing it and shaping the look — homepage, product page, brand feel, key sections. A pure theme setup compresses this to almost nothing; a genuinely custom design stretches it out, because every screen is drawn rather than adapted. Design also includes your feedback rounds, which is where client-side delay first shows up: a design that could be signed off in two days often takes two weeks because approvals sit in an inbox.

3. Build and configuration — one to three weeks

This is the part people picture as "the whole project," and it's genuinely a fraction of it: implementing the design, configuring the theme, setting up collections, navigation, shipping, taxes and payments, and building any custom sections or features. Well-scoped custom features are predictable here; vague ones ("we'll figure out the bundle logic later") are where builds quietly slip.

4. Content and products — the phase everyone underestimates

Loading your catalog — products, variants, images, descriptions, collections — takes real time, and it's usually the step that stalls, because the content often isn't ready. A store's shell can be finished and sitting there waiting weeks for product photography, or copy, or final pricing. This is the honest heart of the timeline: the store is rarely late because of development; it's late because the content to fill it isn't done. More on this below, because it's the lever you control most.

5. Testing and launch — a few days

Before going live, the store needs a real check: test orders through checkout, mobile and browser testing, broken-link and redirect checks, tax and shipping verification, and the launch itself — connecting your domain, and if you're migrating, switching over without dropping SEO. It's short, but it's not optional; the stores that launch with embarrassing bugs are the ones that skipped it to hit a date.

The levers that stretch the timeline

On top of the build type, a handful of things reliably add weeks. If your project has several of these, plan for the upper end of every range above — or beyond it.

A large or messy catalog. Ten simple products load in an afternoon. Thousands of products with variants, options and images — especially if the data is inconsistent — is a project in itself, and no amount of developer speed changes how much data there is to get right.

A migration from another platform. Moving products, customers, orders and URLs off WooCommerce, Magento, Wix or a custom site is its own phase, usually one to a few weeks, and it can't be rushed without risking the SEO you already have. If you're replatforming rather than launching fresh, add this time deliberately.

Custom features and integrations. Anything a theme and apps can't do off the shelf — a custom configurator, unusual bundle logic, a members' area, or syncing the store with your ERP, accounting or warehouse — is build time, not setup time. Integrations in particular can take longer than the storefront itself, because you're keeping two systems in agreement. This is the backend-heavy work I focus on, and it's worth scoping early.

Approval and feedback cycles. This is the invisible one. A build's calendar time is often double its actual work time because of waiting — for feedback, for a decision, for a login, for the final logo. Prompt, consolidated feedback is one of the biggest things that keeps a project on schedule, and it costs nothing.

The part that's on you: content readiness

If you take one thing from this, take this: the fastest-launching stores are the ones whose owners had their content ready before the build started. Real product photography, finished descriptions, final pricing, your logo and brand assets, your policy and about pages — when all of that is waiting to be loaded, the build flows. When it's being created during the build, the store sits finished-but-empty, and the launch date drifts by exactly as long as the content does.

Developers can't fix this from their side, and it's the most common reason a "three-week" store takes two months. So before you're anxious about how fast someone can build, get your products, photos and copy done. It's the single biggest lever you personally control, and it moves the timeline more than any technical choice.

How to launch faster, honestly

There's no trick that safely compresses a real build, but there are reliable ways to avoid losing weeks. Start from a strong theme instead of a fully custom design unless you truly need bespoke. Have your catalog and content ready to load on day one. Agree the scope clearly up front so nothing gets "figured out later" mid-build. Give feedback in prompt, batched rounds. And separate must-have features from nice-to-haves — you can launch a clean, selling store and add the extras later, rather than delaying revenue for polish. Almost every advanced feature can be added to a store that's already live.

The stores that hit their dates aren't the ones with the fastest developer; they're the ones where the scope was clear, the content was ready, and decisions came back quickly. Get those three right and a customised Shopify store in a month is entirely realistic. Get them wrong and no timeline survives.

Shopify store timeline FAQs

How long does it take to build a Shopify store?
A theme-based store set up well is usually a few days to a couple of weeks. A theme customised to your brand with some custom features and a product migration is typically three to eight weeks. A fully custom or headless store runs a few months. The single biggest variable isn't the code — it's how ready your products, photos, copy and decisions are.

Can a Shopify store be built in a week?
Yes, if you keep it to a well-chosen theme, a small and simple catalog, no migration and no custom features — and your product photos and copy are ready to load on day one. The moment you add custom design, a large catalog, a migration or integrations, a week is no longer realistic.

What makes a Shopify build take longer?
Custom design beyond a theme, a large or messy catalog, migrating data and URLs from another platform, custom features that themes and apps can't do, and integrations with your other systems all add time. But the most common cause of delay is client-side: product photos, descriptions and content that aren't ready, and slow rounds of feedback and approvals.

How can I make my Shopify store launch faster?
Have your content ready before the build starts — product data, real photography and copy — because that's the most common thing that stalls a launch. Start from a strong theme instead of a fully custom design, agree the scope clearly up front, and give feedback in prompt, consolidated rounds rather than trickling changes.

How long does migrating to Shopify take?
A migration from another platform is its own phase, usually one to a few weeks depending on how many products, customers and orders you have and how clean that data is. It also has to preserve your URLs and SEO with proper redirects, which is careful work — rushing a migration is how stores lose search rankings they spent years building.

I build Shopify stores end to end — theme customisation through to custom apps, migrations and the integrations that tie a store into your business. See my Shopify development service or get in touch.

Sabre vs Amadeus vs Travelport: Which GDS Should Your Travel Portal Use?

Sunny Badgujar — Thu, 17 Sep 2026 16:54:53 +0000

Originally published at sunnybadgujar.com.

If you're building a travel portal, one of the first real decisions is which global distribution system to connect to — and the three big names, Amadeus, Sabre and Travelport, get compared as if one is simply "the best." They aren't ranked that way in practice. They're three large, mature systems that overlap heavily and differ in ways that matter enormously for your portal and barely at all in the abstract. Here's how they actually differ, and how to choose — from someone who runs a live platform sitting on top of more than one of them.

First, the thing every comparison should say up front: a GDS is a distribution network. It aggregates flights, hotels, car hire and other travel content from thousands of providers and exposes it through one connection, so your portal can search and book across the industry without integrating each airline and hotel chain yourself. Amadeus, Sabre and Travelport are the three that dominate that role globally. All three do fundamentally the same job. So the question isn't "which one is good" — they're all good — it's "which one fits what I'm building and who I'm selling to."

That's why a blanket "use X" recommendation is worth ignoring. The right GDS depends on your target market, the content you need, the commercial terms you can get, and how much engineering you want to take on. Let's go through each of those, then the three systems, then how to actually decide.

The three, at a glance

Here's the honest high-level shape of each. Treat these as tendencies, not laws — all three carry global content, and their exact coverage and terms shift with the deals airlines and agencies strike.

GDS	Typically strongest in	Often chosen for
Amadeus	Europe and broad global coverage	The widest all-round airline and hotel content; strong for globally-minded portals
Sabre	North America	Deep US carrier and agency presence; portals focused on the Americas
Travelport (Galileo / Apollo / Worldspan)	A challenger across several regions	Competitive terms, merchandising and NDC content; strong in select markets

The honest headline: for most portals the deciding factor isn't which brand is "biggest," it's which one has the best content and commercial terms for your specific market. A smaller GDS with a great deal and the right coverage beats the biggest name on paper.

The factors that actually decide it

1. Your target market and routes

This is the first and biggest filter. Where do your customers fly and stay? A portal built for European and long-haul international travel usually finds Amadeus the natural fit; one aimed at North American domestic and cross-border travel often leans to Sabre; Travelport is a serious option across several regions and frequently the one that competes hardest on terms. Match the GDS's regional strength to your actual demand and half the decision is made — because content and fares that are excellent in one region can be thinner in another.

2. Content: air, hotel, car — and NDC

"Flights" isn't one thing. You need to check that the GDS carries the airlines your customers actually want, at competitive fares, plus the hotel and car content if you're selling those. A growing piece of this is NDC (New Distribution Capability) — the newer standard airlines use to distribute richer fares and ancillaries like seats and bags. All three GDSs are building out NDC content, but the depth varies by carrier and by GDS, and it matters more every year. If a specific airline's full fare range is core to your business, verify how each GDS carries it before you choose.

3. Commercial terms and cost

GDS access is a negotiated commercial agreement, not a public price list. Terms vary with your booking volume, market and content needs, and can involve segment fees, minimums and incentives that swing the real cost significantly. This is why the "best" GDS is partly whichever gives you the best deal — a challenger hungry for your segment may offer terms the market leader won't. You negotiate directly with the GDS, or reach one through an aggregator, and the deal is a genuine input to the choice, not an afterthought. I've written more on how these costs feed into a build in what it costs to build a booking engine.

4. The API and the engineering reality

Each GDS exposes its content through its own APIs, and they are not interchangeable — different data models, different booking flows, different quirks and legacy corners. Whichever you pick, the integration is real work: managing sessions and pricing, handling the confirm-price-before-book flow, dealing with time-outs and errors gracefully, and keeping the connection stable in production. The GDS with slightly better content but a far messier API can cost you more in the long run than a marginally smaller one that's cleaner to build on. This is exactly the kind of trade-off worth weighing with an engineer who's integrated one before, not just a salesperson.

Do you have to pick just one?

No — and many serious portals don't. Running more than one GDS widens your content and fare coverage, strengthens your hand on commercial terms, and means you're not wholly dependent on a single provider's uptime or pricing. The trade-off is engineering: every GDS you add is another API, another data model and another set of failure modes to handle.

The right way to do it — and the way I've built it — is to put an abstraction layer between your portal and the GDSs. The rest of your system talks to one internal interface for "search flights" or "book this fare," and behind that interface you can have one GDS today and three tomorrow without rewriting the portal. It also lets you route a search to whichever provider has the best fare or content for that request. If multi-GDS is where you're heading, that architecture is the whole game; I've written it up in detail in how to integrate multiple GDS providers into one booking engine. And if you're leaning toward Amadeus specifically, there's a full walkthrough in integrating the Amadeus API into a B2B travel portal.

How to actually decide

Strip it back to a short, honest process. Start with your market and routes and shortlist the GDS whose regional strength matches your demand — that usually narrows it to one obvious lead and one challenger. Confirm each carries the airline, hotel and car content your customers need, with real attention to NDC for any airline central to your model. Then talk terms with both, because the commercial deal can flip the decision, and factor in the engineering effort of each one's API. If you have the volume and the ambition, plan for more than one from the start by building behind an abstraction layer — but launch with the single best fit rather than waiting to integrate everything.

What you should not do is pick the biggest brand by reputation and assume it's right. I've seen portals over-pay for the market leader when a challenger had better terms and equal content for their region, and I've seen portals under-serve their customers by choosing on price alone and missing the airlines those customers actually wanted. The decision is specific to you — and it's cheap to get right up front and expensive to change once your bookings depend on it.

GDS comparison FAQs

What is the difference between Amadeus, Sabre and Travelport?
All three are global distribution systems that let a travel portal search and book flights, hotels and cars from thousands of providers through one connection. The practical differences are geographic strength (Amadeus is strongest in Europe and globally, Sabre in North America, Travelport competes across several regions), the exact airline and hotel content each carries, their APIs and NDC support, and the commercial terms you can negotiate. For most portals the deciding factor is which one has the best content and terms for your target market.

Which GDS is best for a travel portal?
There is no single best GDS — it depends on where your customers travel, what content you need, and the commercial deal you can get. A portal serving European or global routes often starts with Amadeus; one focused on North America often leans to Sabre; Travelport is a strong option and frequently the challenger on price and terms. The right answer is the GDS whose content and pricing fit your market, not the biggest name.

Can a travel portal use more than one GDS?
Yes, and larger portals often do — to widen fare and content coverage, to negotiate better terms, and to avoid depending on a single provider. The catch is that each GDS has its own API and quirks, so connecting several is far more work than one. The clean way to do it is to build an internal abstraction layer so the rest of your system talks to one interface while multiple GDSs sit behind it.

How much does GDS access cost?
GDS access is a commercial agreement, not a public sign-up, so there is no list price. Terms vary by provider, your booking volume, your market and what content you need, and can involve segment fees, minimums and incentives. You negotiate directly with the GDS or go through an aggregator, and the deal you can get is itself one of the factors in choosing between them.

Do I need a GDS or can I use direct airline APIs and NDC?
It depends on your model. A GDS gives you broad multi-airline content through one connection, which is why most portals start there. Direct airline APIs and NDC can give richer content and better fares for specific carriers, but connecting many airlines directly is a lot of integrations to build and maintain. Many modern portals use a mix — a GDS for breadth plus direct or NDC connections for key airlines — behind a single booking layer.

I build travel portals and booking engines on top of the major GDSs — and I run a live platform that sits on more than one. If you're choosing a GDS or building on top of one, see my travel portal development service or get in touch.

How to Integrate the Amadeus API into a B2B Travel Portal

Sunny Badgujar — Fri, 04 Sep 2026 22:32:19 +0000

Originally published at sunnybadgujar.com.

Amadeus is where most travel portals start, and for good reason: it's the largest GDS, the content is deep, and the modern Amadeus for Developers APIs are plain REST with JSON — no arcane messaging formats to learn on day one. But there's a gap between "I can search flights from a code sample" and "I've shipped a B2B travel portal that sub-agents actually book on." This post is about closing that gap.

I run a travel reservation platform that integrates Amadeus alongside other suppliers end to end — search, pricing, booking, refunds, agent wallets and markup. Below is the integration path I'd hand to someone starting today, in the order the decisions actually come up.

First decision: Self-Service or Enterprise?

Before you write a line of code, you have to know which Amadeus you're building against, because they are not the same product.

Amadeus Self-Service APIs. Sign up on the developer portal, get an API key in minutes, and you're calling a free test environment the same day. REST/JSON, pay-as-you-go pricing in production, no commercial negotiation. Perfect for MVPs, prototypes, and portals with moderate volume. The catch: the content and functionality are a curated subset of full GDS capability.
Amadeus Enterprise (the full travel platform). Full GDS content, ticketing, richer fare and ancillary support — but it requires a commercial agreement, an office ID, and a heavier onboarding. This is what large agencies and consolidators run on.

Practical advice: build your MVP on Self-Service. Its data model and flow mirror the enterprise concepts closely enough that if you keep Amadeus behind an adapter (more on that below), moving up later is an integration change, not a rewrite. Don't block your launch on an enterprise contract you don't need yet.

Everything that follows uses the Self-Service REST flow, because that's where 90% of new B2B portals begin.

Authentication: one token, cached, refreshed

Amadeus uses OAuth2 client credentials. You exchange your API key and secret for an access token, and you send that token as a bearer header on every subsequent call. The token is short-lived — roughly 30 minutes — so you cache it and refresh before it expires rather than requesting a new one per call.

POST https://test.api.amadeus.com/v1/security/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_API_KEY
&client_secret=YOUR_API_SECRET

// response
{ "access_token": "abc123...", "expires_in": 1799, "token_type": "Bearer" }

Wrap this in a small token provider that stores the token in memory with its expiry and hands out a valid one on demand. Requesting a fresh token on every search is a classic early mistake — it adds a round-trip to every request and burns quota for no reason.

Two environments, two base URLs: test.api.amadeus.com serves cached, non-live data for development; api.amadeus.com is production with live pricing and real bookings. They use different credentials. Make the base URL and keys configuration, never hard-coded — you will switch between them constantly.

The core flight flow is three calls, in order

This is the single most important thing to internalise about Amadeus, and it maps directly to how travel actually works: search is indicative, price is live, and only then can you book. Three endpoints, always in this sequence:

Flight Offers Search — POST /v2/shopping/flight-offers. Send origin, destination, dates, passenger counts, cabin. Get back a list of offers, each with a full fare breakdown and an offer object you carry forward. This is what populates your results page.
Flight Offers Price — POST /v1/shopping/flight-offers/pricing. Take the exact offer the customer selected and confirm it live. Amadeus revalidates availability and price and returns the current, bookable fare. This is where you catch price drift before it costs you money.
Flight Create Orders — POST /v1/booking/flight-orders. Send the confirmed offer plus traveller details, and Amadeus creates the booking (a PNR). This is the step that actually reserves seats.

Skipping the middle step is the most expensive bug in the category. If you book straight off the search result, you'll routinely try to sell fares that have already changed or sold out — and you eat the difference or fail the booking at the worst possible moment. The price call exists precisely so you re-confirm the fare the instant before you charge the customer.

Booking is two steps for the same reason. Confirm price live, then take payment, then create the order. If order creation fails after you've charged, you must automatically void or refund — never leave an agent's wallet debited for a PNR that doesn't exist.

Now the part the docs don't cover: this is a B2B portal

A consumer booking site has one customer type. A B2B portal has agents — sub-agents, sub-sub-agents, corporate clients — each of whom logs in, sees their own fares, and books against their own money. That changes the architecture in four concrete ways.

1. Multi-tenancy and roles

Your data model needs a tenant hierarchy from day one: the portal owner at the top, then agencies, then the individual agents who log in. Every booking, every wallet transaction, every markup rule is scoped to a node in that tree. Retrofitting multi-tenancy after launch is painful — bake the agency/agent relationship into your schema and every query before you have live data.

2. The markup engine

Amadeus returns net fares. Your agents must never see the net — they see the price after your markup. So between the pricing call and the response you send to the browser, you run a markup engine that adds a margin. And it's rarely a flat number: markup varies by agency, by route, by airline, by fare class, sometimes as a percentage and sometimes as a fixed amount per passenger.

// conceptual: applied server-side, never in the client
sellFare = netFare + resolveMarkup(agencyId, route, airline, fareClass);
// the agent sees sellFare; the net stays server-side only

Two rules keep this safe. First, markup is applied on the server, always — the net fare must never reach the browser, or an agent will read it in the network tab. Second, you store both the net and the sell price on the booking record, so your reconciliation and commission reports are accurate later.

3. Agent wallets and credit

B2B agents don't pay by card per booking. They top up a wallet (or get a credit line), and each booking debits the balance. That means your booking flow has an extra gate: check the agent has sufficient balance before you call Flight Create Orders, then debit atomically as part of confirming the booking.

Model the wallet as an immutable ledger — append credits and debits, never edit a running total. The balance is the sum of entries. This makes disputes auditable and prevents a whole class of race-condition bugs.
Debit and booking must succeed or fail together. If the Amadeus order fails, the debit reverses; if the debit fails (insufficient funds), the order is never attempted.
Cancellations and refunds credit the wallet back, minus any airline penalty — as a background job with retries, because refund calls fail transiently.

4. Credential and quota management

On Self-Service, the whole portal typically shares one set of production Amadeus credentials, so your rate limiting and quota tracking are portal-wide — one noisy agency hammering search can throttle everyone. Enforce per-agency rate limits inside your own layer so no single tenant can exhaust the shared quota. (On enterprise, you may have per-office-ID credentials, which changes this calculus — another reason to keep Amadeus behind an adapter.)

Keep Amadeus behind an adapter — even if it's your only supplier

It's tempting, when Amadeus is your only integration, to call it directly from your booking code. Don't. Define your own internal types — a FlightOffer, a PriceBreakdown, a BookingResult — and make an Amadeus adapter translate into them. Your search page, booking flow and admin panel work only with your model and never import Amadeus specifics.

You get two payoffs. Moving from Self-Service to enterprise later becomes an adapter change instead of a rewrite. And the day you add a second supplier — a low-cost carrier aggregator, a direct hotel feed, another GDS — you write one more adapter and the rest of the system doesn't notice. That multi-supplier architecture is a topic in itself; I've written it up separately in how to integrate multiple GDS providers into one booking engine.

Caching, rate limits and the test-data trap

GDS calls cost money and are rate-limited, so treat them accordingly:

Cache searches briefly. A 30–120 second cache keyed on route and dates absorbs pagination and repeat searches without re-hitting Amadeus. Never cache long enough to serve a stale fare into a booking — the live price call is your safety net, but don't lean on it to paper over reckless caching.
Rate-limit per agency, inside your layer. As above, the shared Self-Service quota means one tenant can starve the rest unless you police it yourself.
Remember the test environment is not live. Test data is cached and limited — some routes return nothing, prices aren't real, and a "successful" test booking isn't a real reservation. Validate business logic in test, but only trust behaviour you've re-checked against production before you go live.

The admin panel is half the product

None of the above is visible to your operations team unless you build for them. An internal admin panel — showing every booking with its agency, net and sell fare, wallet transaction, PNR and refund state, plus a full audit log of what you sent Amadeus and what came back — is how support resolves a stuck booking at midnight without reading raw API logs. In a B2B portal it's not optional: it's where you manage agents, set markup rules, top up wallets and investigate disputes. Build it alongside the engine, not after.

Pitfalls I'd flag before you start

Never skip Flight Offers Price. Search prices are indicative; confirm live before every charge.
Never let the net fare reach the browser. Apply markup server-side; store both net and sell on the booking.
Make wallet and booking atomic. A retried booking or refund must never double-charge or double-credit an agent.
Don't hard-code the environment. Test and production have different URLs and keys — make them configuration.
Don't call Amadeus directly from business code. The adapter is what lets you grow from Self-Service to enterprise, and from one supplier to many.
Log every request and response for audit. "What exactly did we send and what did they say" is a question you'll be asked constantly.

Get the three-step flow and the B2B plumbing — markup, wallets, multi-tenancy — right, and Amadeus becomes a dependable engine you can build a real agency business on. Rush them, and you'll be reconciling mismatched fares and disputed wallet balances by hand for months. The API is the easy part; the portal around it is the product.

I've integrated Amadeus and other GDS suppliers into a live travel platform — search, pricing, booking, markup, agent wallets and refunds. If you're building a B2B travel portal, you can read more about my travel portal development work or get in touch.

Why Your SQL Server Database Is Slow (and How to Fix It)

Sunny Badgujar — Sat, 29 Aug 2026 22:21:25 +0000

"The app is slow" is one of the most common things a business tells me when they get in touch. Pages that loaded in a blink now take five or six seconds. Reports time out. Everything gets worse at the busiest time of day — exactly when you can least afford it. And the database server sits there pinned at 100%, so the assumption is: we've outgrown the hardware, we need a bigger machine.

Sometimes that's true. Usually it isn't. In most systems I've looked at, throwing more CPU and RAM at the problem just buys a few months and a bigger bill, because the real cause is still sitting in the code. Below is the order I actually work through when a SQL Server database has slowed to a crawl — roughly cheapest and highest-impact first.

1. Missing indexes — the number one culprit

An index is what lets the database jump straight to the rows it needs instead of reading the entire table. Without the right one, a query for a single customer might scan all two million rows every single time it runs. On a small table nobody notices. As the data grows, that same query goes from milliseconds to seconds, and the slowdown creeps up so gradually that no single day feels like the day it broke.

The good news is this is often the single biggest win available, and it's low-risk. Adding a well-chosen index to a column you filter or join on regularly can turn a multi-second query into an instant one, with no application changes at all. SQL Server will even tell you which indexes it wishes it had — the trick is knowing which of those suggestions to trust and which to ignore, because too many indexes slow down writes.

2. The N+1 query problem

This one hides inside the application code, and it's everywhere. It looks like this: you load a list of 50 orders with one query, then — often without realising — the code fires off one more query per order to fetch its customer. That's 51 round trips to the database to show a single page. With ORMs like Entity Framework it's especially easy to write by accident, because the extra queries are invisible in the C# — they only show up when you watch what actually hits the database.

Each individual query is fast, so nothing looks wrong in isolation. But the round trips add up, and under load they multiply. The fix is usually to load the related data up front in one query instead of hundreds.

3. SELECT * and pulling back more than you need

When a query grabs every column and every row "just in case," the database has to read, transfer and materialise all of it — including large text and image columns the page never even displays. Multiply that by every user hitting the page and you're moving far more data than the feature actually needs.

Asking only for the columns and rows you'll use — and paging large lists instead of loading ten thousand records into a dropdown — cuts the work at the source.

4. Queries that can't use their indexes

Sometimes the index exists and the query still ignores it. This usually comes down to how the query is written: wrapping a column in a function, doing type conversions in the wrong place, or leading a search with a wildcard all quietly force the database to scan the whole table anyway.

These are subtle, and you only find them by reading the execution plan — SQL Server's own explanation of how it ran the query. Reading plans is most of what practical performance tuning really is; the fixes are often a one-line change once you can see the problem.

5. Blocking and locking under load

If the app is fine when it's quiet and falls apart when everyone's using it, the problem may not be any single slow query — it may be queries getting in each other's way. When one operation holds a lock longer than it should, everything else queues up behind it, waiting. Users experience this as random freezes that are impossible to reproduce on a quiet test environment.

6. Statistics and fragmentation the server forgot to maintain

SQL Server decides how to run a query based on internal statistics about your data. If those go stale, it can start making bad decisions, choosing a slow plan because its picture of the data is out of date. On a lot of the systems I inherit, routine maintenance was never set up, so performance degrades month after month for reasons nobody can see.

7. Only now: is it actually the hardware?

Sometimes, after all of the above, the honest answer is yes — the workload has genuinely outgrown the machine. But by then you're making that decision with evidence instead of a guess. I've seen a "we need a bigger server" emergency turn out to be two missing indexes and one N+1 query — fixed in an afternoon, no new hardware.

A bigger server makes a slow query slow more quickly. It doesn't make it fast. The fix is almost always in the queries, not the hardware.

How I approach a slow database

The method is the same every time, and it's deliberately boring: measure first, guess never. Find the queries that actually hurt (SQL Server tracks which run most often and cost the most time), read each one's execution plan to find the real cause, apply one targeted fix, then re-measure to prove it helped — and know when to stop.

I'm Sunny Badgujar, a freelance full-stack .NET developer. I do SQL Server performance audits and query tuning for .NET applications — find the real bottleneck, fix it, and prove the difference with numbers. If your app is slow and you're not sure why, tell me what you're seeing.