Dealing with recurring CPU spikes, slow queries, or costly downtime? We connect Tucson companies with expert DBAs to tune performance, eliminate bottlenecks, and lower costs. No junior handoffs, ever. SQL Server is all we do.
Talk to a senior DBA
A senior DBA reads this (not a sales rep) and replies within one business day. No obligation.
You see the findings and the price before you commit.
By clicking, you agree to our Terms of Use and Privacy Notice.
Prefer to talk? A senior DBA is reachable at 1-877-891-1870
SQL Server consulting in Tucson: the short answer
Red9 delivers senior-only SQL Server consulting, performance tuning, managed DBA services, and emergency response to organizations across Tucson and Pima County, including Oro Valley, Marana, Sahuarita, Vail, Green Valley, and the Catalina Foothills. Since 2014 this engine has been our only trade. The free 145-point health check opens every engagement. We hold 120+ clients, from seed-stage startups up to the Fortune 100; Managed Services and Emergency Services clients get a production incident answered inside 15 minutes, and readings are taken on both sides of every change.
Looking for a SQL Server consultant covering Tucson and southern Arizona? Book your free assessment.
Tucson's economy is built on carefully measured things: missiles, mirrors, copper, and produce. The databases behind them fill fast with test results, sensor readings, and haul-truck telemetry, and growing tables need partitioning.
Tucson's largest private employer builds missile and defense systems on the south side, Davis-Monthan sits east of it, and an optics and photonics cluster surrounds the University of Arizona. Test and measurement data here arrives in volume and gets kept, so retention and partitioning lead. We size that growth.
Southern Arizona copper operations ring the city, and the surface-mining arm of a global equipment maker runs from downtown Tucson. Mining databases collect telemetry, maintenance history, and assay results around the clock with no real maintenance window. We place integrity checks in the quiet hours.
A university medical center, a large independent hospital, and the campus research operation put a substantial clinical data load into this metro, with health-software vendors alongside. Those vendors hit the cloud sizing question first, which we answer by replaying the real workload: see case #2 below.
A large share of America's winter vegetables enters through Nogales and moves north on I-19 through Tucson, supporting a cold-chain distribution sector with tight timing and thin margins. One query in a distribution estate was reading 2.16 billion pages a day: case #3 below has the readings.
We work with organizations across the region: Tucson, Oro Valley, Marana, Sahuarita, Vail, Green Valley, and the Catalina Foothills, out to Nogales, Sierra Vista, and Casa Grande, and statewide across Arizona, all over secure remote access. Work is booked on Mountain Standard Time, which Arizona keeps all year.
A principal-grade opinion on the sizing, edition, or architecture question a Tucson team is about to answer with a purchase order. Cheaper to test than to reverse.
From $4,995 / 20-hr block (hours do not expire)Senior administrators running the estate day to day: alerting, patching, verified restores, statistics and index upkeep, and growth watched before it becomes a purchase.
From $395 / moWhoever answers has already fixed this failure elsewhere, with a 15-minute response for Managed Services and Emergency Services clients.
From $2,500 / incidentThe workload sorted by daily cost, then indexed, re-keyed, or rewritten. A statement with four joins in it usually needs the SQL changed, and we do that work rather than route around it.
Version moves, Azure SQL, or AWS RDS, sized against a replayed workload before anybody commits to an instance tier. SQL Server 2016 loses extended support on July 14, 2026, and 2017 15 months later.
145 read-only checks over configuration, backups, security, and query cost, returned in the order that repays soonest. Point the same audit at your own instance for nothing.
Recovery timed rather than assumed, which matters where monsoon storms take out power most summers. We design and tune clusters and Always On Availability Groups, and add log shipping, replication, or Change Data Capture (CDC) when only changed rows need to move.
Preparation on the databases your team wants an assistant reading, ChatGPT (OpenAI) or Claude (Anthropic), together with the RAG pipelines, vector search, and analytical load those tools aim at SQL Server. When reporting starts crowding transactions, we move the offload, SSRS and Power BI datasets included, onto Snowflake, Redshift, or the warehouse you already have.
"The single biggest benefit has been performance gains and tuning associated with migrating to AWS and a newer version of SQL Server with Always On clustering. Red9 was an integral part of this process. Red9 has incredible expertise both in SQL migration and performance tuning. The deep level of knowledge of MSSQL is incredible and the combined experience and expertise has been a huge asset."
"Thank you Red9! We greatly appreciate all the team's hard work."
"Red9 first gave us the overview of where our difficulties were coming from. We were able to identify what specifically needed to be resolved by the app developer and what could be resolved by ourselves."
Four stages, counted in days, and the senior DBA who runs the audit does the work that follows. The ranked plan and its price arrive before any commitment.
Which instances the business leans on, how the symptom presents to the people who report it, and what changed in the two weeks beforehand. That last question is worth more than any dashboard.
145 checks across instance configuration, whether the backups restore inside your target, where security is exposed, and what each statement costs a day, all ranked by return. Prefer to see it yourself? The same read-only audit runs on your own instance at no charge through our self-serve Health Check.
A single session on the report in priority order, hours and cost against each finding, and no line hidden in an appendix.
Once approved we work the plan and capture readings around each change, so every gain is checkable by your own engineers. Managed services afterwards stop the estate drifting back.
Three real Red9 projects, tracked from the opening review to the final reading. Each client captured the figures on both sides of the work. Names stay out of it, as agreed.
The problem. A stored procedure was running at 30,682 ms with 18,922 ms of processor time and 12,850,589 logical reads per execution. Inside it was a single SELECT carrying four joins, which is usually a sign that one statement has been asked to answer several different questions at once.
What we did. We rewrote the SELECT as two separate statements combined with UNION. Each half now filters on something an index can seek, so the engine stops choosing a compromise plan that suits neither branch. The readings were captured on the same procedure before and after.
18,922 ms of CPU down to 1,249 ms, with no schema change involved.
The result. The procedure returns in under a second and touches 18,532 pages instead of 12.85 million. Nothing about the database schema changed; the statement simply stopped asking the engine to do the impossible in one pass.
What the plan showed. The combined predicates left the optimizer no selective starting point, so it scanned the largest table and joined outward. Reads of nearly 13 million for a modest result set are the signature of that shape.
What we changed (identifiers generalized for privacy):
-- Procedure: 30,682 ms, 18,922 ms CPU, 12,850,589 reads per execution. -- before: one SELECT with four JOINs and a combined WHERE clause -- after : two SELECTs, each with a selective predicate, combined by UNION SELECT ... FROM dbo.[header] h JOIN dbo.[lines] l ON l.headerId = h.id WHERE h.accountId = @accountId UNION SELECT ... FROM dbo.[header] h JOIN dbo.[lines] l ON l.headerId = h.id WHERE h.referenceNo = @referenceNo; -- rollback: prior procedure text retained
Two selective statements beat one general one: 685 ms, 1,249 ms of CPU, 18,532 reads.
The problem. A healthcare software company was planning a move from a 48-core, 200GB on-premises SQL Server 2008 R2 Enterprise box to an Azure SQL Managed Instance, and needed to know which instance size would actually hold. An earlier test at 4 cores and 20GB had not been convincing, so the question was whether doubling to 8 cores and 40GB was enough.
What we did. We stopped estimating and replayed the real thing. A sampled production workload of 1,981 distinct commands and 613,716 executions was replayed against the 8-core, 40GB Managed Instance, and duration, CPU, and read counts were compared with the existing production server over the same set.
About 38% slower on a sixth of the cores, which is what the client weighed the target size against.
The result. The client got a defensible answer instead of a vendor estimate: 8 cores and 40GB would carry the workload, with reads improving while duration and CPU both gave up ground. The replay evidence sat behind the budget decision rather than a calculator's output.
What the replay showed. Distributed Replay with a sampled production trace exercises the real statement mix, real parameter values, and real concurrency, which a synthetic benchmark cannot. Here it also exposed the wait profile: 88% of waits were SOS_WORK_DISPATCHER, the engine waiting for work rather than for a resource.
How the comparison was framed (identifiers withheld):
-- Replay comparison: on-prem 48 core / 200GB vs Azure MI 8 core / 40GB -- workload : 1,981 distinct commands, 613,716 executions, sampled from production -- duration : 334 s -> 544 s overall (~38% slower on the smaller target) -- cpu (ms) : 359,088 -> 571,428 overall -- reads (8k) : 72,675,940 -> 45,839,276 (37% fewer) -- waits : 88% SOS_WORK_DISPATCHER (idle, waiting for work)
Every figure was handed over with the replay method attached, so the client could rerun the comparison against any other candidate size.
The problem. A wholesale distributor had a large multi-join query against its work-order lines table running about 58 times a day. Each execution averaged 22,067.73 ms, burned 17,316.24 ms of processor time, and the statement was accounting for 2,160,753,402 reads a day. 22 seconds for an operational query is the kind of number people stop mentioning and start planning around.
What we did. We built a covering index on the two columns the query joins and filters on, with the two quantity columns it returns included, and created it online with a fill factor of 80 so nothing had to stop. Query Store recorded before and after.
17,316.24 ms of CPU down to 79.94 ms, with about 21 minutes of SQL time a day recovered.
The result. The query answers in under two tenths of a second and the estate stopped moving more than two billion pages a day for it. Because the index was built online, it went in without a maintenance window.
What the review found. The work-order lines table had no index leading with the join column, so every execution scanned it and then looked up the quantity fields row by row. At that table size the per-execution read count reached 37 million.
What we changed (identifiers generalized for privacy):
-- Work-order query: ~58x/day, 22,067.73 ms avg, ~2.16B reads/day. CREATE NONCLUSTERED INDEX IX_Red9_WorkOrderLines_OrderLine_Source ON dbo.[WorkOrderLines] (orderLineId, productionSource) INCLUDE (sentWorkOrderQuantity, workOrderQuantity) WITH (FILLFACTOR = 80, ONLINE = ON); -- rollback: DROP INDEX IX_Red9_WorkOrderLines_OrderLine_Source provided
Covering the join and the output turned the scan into a seek: 180.91 ms a run, 79.94 ms of CPU, and 879,744 reads a day.
Those figures were all measured on other companies' estates. Give us 30 minutes and we will measure yours.
Get a Free SQL Server Assessment ➜Rather talk it through? A senior DBA answers at 1-877-891-1870.
15 years or more behind the person holding your credentials, and no handover to a junior after the sale.
Since 2014 SQL Server has been the only engine we work, with 10,000+ audited databases behind the opinion.
Duration, reads, and CPU logged either side of every change, in tooling your engineers already run.
Monsoon night or holiday weekend, Managed Services and Emergency Services clients reach a senior DBA within 15 minutes.
No, and remote is how virtually every client of ours operates, Tucson included. A senior DBA stays reachable through your whole Tucson workday on Mountain Standard Time, with 24/7/365 emergency cover on top for Managed Services and Emergency Services clients. Access stays under your control from start to finish: we come in over your VPN or bastion host on least-privilege logins you create and can withdraw immediately, with further controls above that, and each change arrives as a script your engineers read before it runs.
How the three options behave on the day a Tucson production database becomes everybody's problem at once.
| Red9 | In-house DBA hire | Generalist IT / MSP | |
|---|---|---|---|
| Seniority | Principal-grade SQL Server specialists averaging 15+ years, with no junior bench below them. | One hire holds the whole discipline, and Phoenix pay keeps poaching that person. | Generalists who reach SQL Server between many other systems. |
| SQL Server focus | SQL Server is all we do. | Shared out across everything else the role covers. | One item on a long supported list. |
| Emergency response | Cover every hour of the year, and a 15-minute response for Managed Services and Emergency Services clients. | What one person can hold, minus sleep and leave. | A queue where your outage waits its turn. |
| Proof | Numbers taken around each change that your team can reproduce. | Rarely written down where anyone can check it. | Summarized in prose instead of measured. |
| Cost model | A scoped project, a monthly retainer, or one incident, and no salaried role idling in the gaps. | A loaded Tucson salary of roughly $110,000 to $135,000, plus benefits and the vacancy before it. | Rolled into a broader invoice with no database line to question. |
| Ramp-up | Reading your plans within the week. | Months to recruit, then months to learn the estate. | Slow to start, and the history gets retold every ticket. |
Senior SQL Server cover on a Pima County estate can be in place inside a week. Get a Free SQL Server Assessment ➜
Founder & Partner
25+ years making SQL Servers faster.
Chief Operating Officer
Chief Revenue Officer
Behind the three of them works a senior-only DBA bench averaging 15+ years, and one named lead answers for your result throughout.
We support Tucson-area teams over secure remote access, across the city, Oro Valley, Marana, Sahuarita, Vail, and Green Valley. The same senior DBA answers whether the instance sits near the airport, on a campus network, or at a mine site south of the city.
Coverage runs across Pima County and the rest of Arizona. Explore the areas we serve.
Five checks worth running before anyone gets your credentials.
Ask what share of their year goes into SQL Server. A specialist and a generalist give the same answers until the problem gets strange.
Get the name and the years for whoever will hold the credentials, in writing, and confirm it does not change later.
For any cloud move, ask whether the recommendation comes from a calculator or from your own traffic replayed against candidate instances.
Response time and eligibility, as numbers, inside the agreement rather than the pitch.
Ask whether index work can be done online. On an estate with no real maintenance window, that answer decides how much gets fixed.
| Headquarters | Alpharetta, GA (Atlanta metro) |
|---|---|
| Founded | 2014 |
| Focus | Microsoft SQL Server only |
| Team | Senior-only DBAs, 15+ years average experience |
| Clients | 120+, from startups to the Fortune 100 |
| Databases audited | 10,000+ |
| Rating | 4.9 out of 5, 120+ reviews |
| Emergency response | 15 minutes, 24/7/365, for Managed Services and Emergency Services clients |
| Engagement models | Scoped project, monthly retainer, or per-incident |
| Service area | Tucson, Pima County, and southern Arizona, plus nationwide via secure remote access |
Yes. Red9 covers Tucson and Pima County, out through Oro Valley, Marana, Sahuarita, Vail, Green Valley, and the Catalina Foothills, and one senior SQL Server consultant owns the account throughout. Remote is what almost every client of ours relies on, and it means a principal-grade DBA is inside your instance in minutes rather than scheduling a drive across the valley. On top of that, Managed Services and Emergency Services cover brings a 15-minute emergency response.
15 minutes, any hour, any day of the year, and a senior DBA answers instead of a ticket queue. This response-time SLA is available to current Managed Services clients and Emergency Services clients. See Emergency Services ➜
Nothing is quoted before the free 145-point health check, because a scope without evidence is a guess with a price on it. Afterwards, managed services and remote DBA run from $395/mo, a 20-hour senior DBA block is $4,995 and the hours do not expire, and 24/7 emergency response starts at $2,500 per incident. Held against a loaded Tucson DBA salary of $110,000 to $135,000, shown in the comparison above, a month on retainer works out near four percent of a month of that hire. Larger scopes get a firm figure after the check.
Often fewer than the current box has, and the way to find out is to replay the real workload against candidate sizes. We capture a sample of production traffic and replay it against candidate instance sizes, then compare duration, CPU, and read counts against the existing server. On one benchmark, described in case #2 above, an 8-core Azure Managed Instance ran about 38% slower than a 48-core on-premises server on duration while cutting reads 37%, which changed the target size the client was budgeting for.
Whichever the plan tells us, and when one statement carries four joins and several access patterns the answer is usually a rewrite. When a single SELECT tries to satisfy several access patterns at once, the optimizer settles on a shape that suits none of them and reads far more than the result needs. Splitting it into two statements joined by UNION lets each half use an index properly. One procedure like that, in case #1 above, came down from 30,682 ms to 685 ms, with reads falling from 12,850,589 to 18,532.
It means the unclean shutdown is a routine event here, so plan for it. Run a consistency check after any hard power loss instead of assuming recovery caught everything, keep the log backups frequent enough that the gap you lose is measured in minutes, and hold a secondary copy outside the same monsoon cell. Arizona skipping daylight saving helps in one small way: your job schedules never shift twice a year, so the maintenance window you set is the one you get. Read the HA guide ➜
Yes. Tucson nonprofits and government agencies get the free 145-point health check on identical terms, and it comes back as 145 findings in risk order with a price against each one, phrased for a board packet or a county procurement review. Managed services and remote DBA run from $395/mo. A 20-hour senior block is $4,995 and the hours do not expire.
Version coverage, supported cloud platforms, and how a standard engagement is put together sit on our SQL Server consulting page.
Half an hour is enough to show where your SQL Server is losing speed, uptime, and budget, and what recovering each takes. The free SQL Server assessment gives you the findings and the figure before anything is agreed.
Schedule My Call Now ➜Rather talk it through? A senior DBA answers at 1-877-891-1870.
