# Database Performance Problems Founders Can Spot Without SQL
Database performance for startups is one of the most common sources of slowness, user complaints, and infrastructure costs - and it is almost entirely diagnosable from user-visible symptoms and team behaviors, without ever looking at a SQL query.
I have worked with founders who assumed their database was fine until a specific event exposed the problem. One marketplace client had users complaining that the main listing page was "slow sometimes." The engineering team had been saying it was "just occasional network latency." After two months of those complaints, I did a one-hour review. The main listings query had no index on the date filter and was doing a full table scan across 800,000 rows every time the page loaded. On a quiet Tuesday it took 400ms. On a busy Friday evening it took 8 seconds.
The team had not lied - they had not looked. And the founder had not known what questions to ask. This article gives you those questions.
Symptom 1: Pages That Load Fine for Small Accounts and Slowly for Big Ones
If some users have a fast experience and some have a slow experience, and the slow users tend to have more data - more orders, more contacts, more history - this is a classic database performance pattern.
The technical cause is almost always missing database indexes or inefficient queries that scan all data for a user rather than looking up only what is needed. As a user's data grows, so does the time to process it.
What to ask your engineering team: "Do we have indexes on the columns we use most often to filter data for a specific user or account?" If they hedge or say "we think so," that is not a yes.
What the right answer sounds like: "Yes, we have database indexes on user_id, account_id, and the date columns we use for filtering. Here is the query plan for our most common queries." Engineers who understand this can show you evidence, not just reassure you.
A good signal that this is the problem: ask your team "does our slowest user have significantly more data than our average user?" If yes, and if performance degrades proportionally to data volume, indexes are almost certainly the issue.
Symptom 2: Slowdowns That Happen at Specific Times of Day
If your product is fast in the morning and slow in the evening, or fast on weekdays and slow on weekends, you are seeing a load-related database problem.
This happens when your database is sized for average load but not peak load. During high-traffic periods, the database becomes a bottleneck. Queries queue up. Response times increase. At extreme load, timeouts start happening.
What to ask: "What are our database CPU and memory utilization numbers at peak versus off-peak?" Most cloud databases (AWS RDS, Google Cloud SQL, Supabase) provide this data in their monitoring dashboards without requiring any SQL knowledge to read.
If peak utilization is above 70-80%, you are regularly hitting capacity constraints. If it spikes to 90%+ during busy periods, those are your slow periods.
The solutions range from simple (upgrade the database instance size) to architectural (add caching, add read replicas, optimize the heaviest queries). Simple solutions are cheap and fast. Architectural solutions are more involved but scale further. Your team should be able to tell you which one applies.
Symptom 3: Background Jobs That Take Hours
Most startups have background jobs - automated tasks that run on a schedule. Sending weekly summary emails. Generating reports. Syncing data with external systems. Calculating metrics.
When these jobs take hours to run, it is almost always a database performance problem. The job is doing a lot of database work - reading or writing large amounts of data - in an inefficient way.
The business impact is subtle but real. Background jobs that run for hours consume database resources during their run time. During a long job, other database operations compete for those resources. Users experience slowdowns during background processing windows.
Beyond performance, long-running jobs create fragility. Jobs that should complete before the next scheduled run sometimes do not, causing overlapping runs. Jobs that hit unexpected data create failures that cascade.
What to ask: "How long do our slowest scheduled jobs take to complete, and what are they doing?" If the answer involves jobs that take more than 30 minutes and touch large amounts of data, ask specifically: "Are these jobs using batching and pagination, or are they trying to process all the data at once?"
Processing large datasets one record at a time, or loading everything into memory before processing, is the most common cause of slow background jobs. Proper batching - processing in chunks of 500 or 1,000 records - is the standard fix.
Symptom 4: Error Spikes Around Specific Features
If your error monitoring shows spikes in timeouts or failures correlated with specific features or user actions, the database is usually the bottleneck.
A common pattern: a feature that works fine individually but fails when many users use it simultaneously. Individual requests complete in 2 seconds. Under concurrent load, requests pile up waiting for the database, some time out, and you get an error spike.
This is a connection pool exhaustion problem or a locking problem. Both are database performance issues with observable symptoms: error rate spikes during high-traffic periods, specifically for features that do significant database writes or complex reads.
What to ask your team: "Do our error spikes correlate with high traffic? Which features do they originate from?" If the pattern is consistent, ask specifically: "Are we seeing database connection timeouts or lock wait timeouts in the error logs for those spikes?"
Connection pool exhaustion means your application is trying to use more database connections than are available. Fixing it usually involves either increasing the connection pool size, implementing connection pooling middleware, or optimizing queries to hold connections for less time.
Symptom 5: Database Costs Growing Faster Than User Growth
This is a financial signal, not a performance signal, but it tells you the same story.
If your database infrastructure costs are growing at 2x or 3x the rate of your user growth, you have an efficiency problem. Database costs should scale roughly linearly with usage. If they are scaling faster, you are either running inefficient queries that consume more resources per request than necessary, or you are storing data in a way that requires expensive compute to process.
What to look at: your cloud provider's cost breakdown by service. Most providers show database costs separately. If your database costs are a large and growing percentage of your infrastructure spend, that warrants investigation.
What to ask: "What are our most expensive database operations? What queries consume the most resources?" Your database provider's monitoring tools can usually show you this without any SQL knowledge on your part - just a look at the "slow query log" or "top queries by resource consumption" dashboard.
What to Actually Do With This Information
The goal of understanding these symptoms is not to diagnose the database problem yourself - it is to have an informed conversation with your engineering team that surfaces problems early and verifies they are being addressed.
If you recognize two or more of these patterns in your product, bring them to your team with specific questions, not vague concerns. "Users with large accounts say the dashboard is slow" is a specific enough complaint to drive investigation. "Is our database performance okay?" is too vague to be actionable.
Ask for metrics, not reassurance. "I think it's fine" is not an answer. CPU utilization percentages, query execution times, and error rates are answers.
And if your team cannot answer these questions with data, that itself is important information - it means you do not have the monitoring in place to know what your database is actually doing. That is a gap worth closing before it becomes a production incident.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr