Find and fix slow Supabase queries before upgrading your database
Trace slow Supabase screens to the real query. Review plans, indexes, permissions and pagination before paying for more database capacity or migrating.
A slow screen is evidence of a customer problem, not yet evidence that Supabase is too small. Find where the time goes, inspect the work the database performs and test a focused change under the permissions customers actually use.
Choose one slow customer journey
Start with a complaint you can reproduce: opening a project, searching records or loading a customer's report history. Write down which account, data size, device and action produce the delay. A database dashboard average cannot explain a particular screen by itself.
Follow the request from the browser through your application to the database and back. Separate network waiting, connection acquisition, SQL execution, response size and rendering. The product might be making many small calls sequentially, downloading too much data or waiting on an unrelated provider.
Collect timings without recording private customer documents or raw secrets. Keep a request reference that lets an engineer correlate the relevant stages. You want enough evidence to find the slow path, not a new store of customer information copied into logs.
Test with the data and role that make it slow
A query on an empty development table tells you little about a workspace with months of history. Use a safe representative dataset and the same filters, ordering, page size and access role as the application. Include both a small workspace and a large one.
Supabase row level security is part of the work performed for the customer. An administrative query that bypasses those policies may appear quick while the signed-in journey remains slow. Include ownership and membership checks in the investigation instead of treating them as an optional layer.
Be precise about what success means. The right rows must still appear in the right order, and another workspace's rows must remain inaccessible. An optimization that returns incomplete results or weakens isolation has not solved the business problem.
Ask what the query plan is actually doing
PostgreSQL EXPLAIN shows the plan chosen for a query. EXPLAIN ANALYZE runs the query and adds observed work. It can change data when used on a modifying statement and can add load, so an engineer should choose the environment and query carefully.
Look for a mismatch between expected and actual row counts, repeated work inside loops, expensive sorting and how much data is inspected before returning a small result. The cost numbers in an estimated plan are not elapsed milliseconds. They are useful for understanding a plan, not a customer-facing speed claim.
A sequential scan is not automatically wrong. Reading a small table or a large share of its rows may be cheaper than using an index. The question is whether the chosen plan makes sense for the actual dataset and request, not whether the word index appears in the output.
Choose an index for a query, not for a column name
Indexes can help locate, join or order the rows a query needs. Their usefulness depends on the actual conditions, data distribution and index structure. Ask the engineer to name the query an index serves and show the plan before and after it is added.
Supabase's query optimization guidance also highlights the cost of over-indexing. Each additional index consumes storage and has to be maintained as data changes. Adding one to every column is not a performance strategy. Planner statistics and the way the query is written deserve attention too.
Plan how the index will be created on a busy database. Default creation can block writes; concurrent creation has its own restrictions and costs. Do not paste an AI-generated migration into production simply because the SQL looks short. Rehearse the operation and know how to identify an unfinished or invalid index.
Remove work the customer did not need
A history screen usually needs the current page, not every report and its full generated text. Fetch the fields and bounded number of rows that serve that screen. Give pagination a stable ordering, including a tie-breaker when several items share the same timestamp.
For large histories, consider whether cursor-based pagination fits the product better than increasingly deep offsets. Check how insertions and deletions affect navigation. A faster first page that skips or repeats items as customers move through their history needs further work.
Look for repeated per-row requests and unnecessary exact counts. If caching is considered, include the account scope and freshness requirement. Serving another workspace's data quickly is a security failure, and serving a stale report can still break the customer task.
Verify the journey, then decide whether capacity is needed
Compare the same customer action on representative data before and after the change. Include repeated runs and simultaneous activity, rather than one favorable result with a warm cache. Check that writes, background jobs and other important screens have not become worse.
Track both database execution and the full time until the customer can use the screen. If SQL became faster but the page still waits, continue along the request path. If the workload genuinely exhausts available resources after sensible query changes, a capacity upgrade can be the right decision.
Bring the slow action, a reproducible example and the relevant timing to an engineering discussion. That is enough to start. You do not need to decide in advance whether the answer is an index, an application change or a different database plan.
Frequently asked questions
Should I upgrade Supabase as soon as a screen becomes slow?
First trace the customer action. A query, connection wait, oversized response or repeated application calls can cause slowness. Upgrade capacity when the measured workload shows it is needed, not merely because one screen is slow.
Does a sequential scan mean a database index is missing?
Not always. A scan can be appropriate for a small table or a query returning much of the data. Compare the actual plan, row counts and workload before deciding whether an index helps.
Can I disable row level security to make Supabase faster?
Do not remove customer isolation as a performance fix. Investigate the policy and its access paths using the customer's role, then verify both speed and the allowed and denied results.