mirror of
https://github.com/supabase/supabase.git
synced 2026-10-09 11:25:06 +03:00
Closes DOCS-1057 Contributes to DOCS-1052 ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## Problem We have hundreds of MDX lint warnings in our docs going against style best practices. ## Solution Remove and replace in context the following: - PostgreSQL. There was only one. There was concern about exceptions, but I found none. - Just - Quickly - Actually ### What changed Edits follow the [Google developer documentation style guide](https://developers.google.com/style): concise, direct, active voice. The flagged words were removed when the sentence still read well, or replaced when meaning needed to be preserved. ### Common patterns | Flagged word | Approach | Example | |---|---|---| | **just** (filler) | Removed | "you just installed" → "you installed" | | **just** (limiting) | **only** | "just one row" → "only one row" | | **just like** | **like** / **the same as** | "function just like regular users" → "function like regular users" | | **not just** | **not only** | "not just errors" → "not only errors" | | **quickly** (performance) | **efficiently** or removed | "find rows quickly" → "find rows efficiently" | | **quickly** (time) | **soon** / **rapidly** / removed | "expires too quickly" → "expires too soon" | | **actually** (filler) | Removed | "actually execute" → "execute"; "is actually the most common" → "is the most common" | ## Tophatting 1. See the diff. 2. See that content continues to make sense in context. 3. Locally, `cd apps/docs` and run `pnpm run lint:mdx`. 4. Search for "just," "actually," "quickly", and "PostgreSQL" and see there are 0 warnings. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated wording across quickstarts, guides, and troubleshooting articles for grammar, clarity, and consistent step-by-step phrasing. * Clarified key concepts including Row Level Security policy evaluation across Supabase products, deferred foreign key constraint behavior, and when `EXPLAIN ANALYZE` executes queries (and related side effects). * Refined several troubleshooting instructions and added guidance to cap log payload size to reduce billed Logs Ingest volume. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Nik Richers <nrichers@gmail.com> Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
43 lines
2.7 KiB
Plaintext
43 lines
2.7 KiB
Plaintext
---
|
|
id: 'performance'
|
|
title: 'Performance Tuning'
|
|
description: 'Getting the best results out of your Supabase project'
|
|
---
|
|
|
|
The Supabase platform automatically optimizes your Postgres database to take advantage of the compute resources of the plan your project is on. However, these optimizations are based on assumptions about the type of workflow the project is being used for, and it is likely that better results can be obtained by tuning the database for your particular workflow.
|
|
|
|
## Examining query performance
|
|
|
|
Unoptimized queries are a major cause of poor database performance. To analyze the performance of your queries, see the [Debugging and monitoring guide](/docs/guides/database/inspect).
|
|
|
|
## Optimizing the number of connections
|
|
|
|
The default connection limits for Postgres and Supavisor is based on your compute size. See the default connection numbers in the [Compute Add-ons](/docs/guides/platform/compute-add-ons) section.
|
|
|
|
If the number of connections is insufficient, you will receive the following error upon connecting to the DB:
|
|
|
|
```shell
|
|
$ psql -U postgres -h ...
|
|
FATAL: remaining connection slots are reserved for non-replication superuser connections
|
|
```
|
|
|
|
In such a scenario, you can consider:
|
|
|
|
- [upgrading to a larger compute add-on](/dashboard/project/_/settings/compute-and-disk)
|
|
- configuring your clients to use fewer connections
|
|
- manually configuring the database for a higher number of connections
|
|
|
|
### Configuring clients to use fewer connections
|
|
|
|
You can use the [pg_stat_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW) view to debug which clients are holding open connections on your DB. `pg_stat_activity` only exposes information on direct connections to the database. Information on the number of connections to Supavisor is available [via the metrics endpoint](../telemetry/metrics).
|
|
|
|
Depending on the clients involved, you might be able to configure them to work with fewer connections (e.g. by imposing a limit on the maximum number of connections they're allowed to use), or shift specific workloads to connect via [Supavisor](/docs/guides/database/connecting-to-postgres#connection-pooler) instead. Transient workflows, which can scale up and down rapidly in response to traffic (e.g. serverless functions), can especially benefit from using a connection pooler rather than connecting to the DB directly.
|
|
|
|
### Allowing higher number of connections
|
|
|
|
You can configure Postgres connection limit among other parameters by using [Custom Postgres Config](/docs/guides/platform/custom-postgres-config#custom-postgres-config).
|
|
|
|
### Enterprise
|
|
|
|
[Contact us](https://forms.supabase.com/enterprise) if you need help tuning your database for your specific workflow.
|