Files
0aa7b4965f chore(docs) Remove instances of let's to resolve mdx lint warnings (#47013)
Contributes to DOCS-1052

Contributes to DOCS-1057

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Resolves linting warning for "let's" and adds an exception for product
name.

## Tophatting

1. Read the diff and see if changes make sense in context.
2. Run `pnpm lint:mdx`, search for "let's" and see no instances. 


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Updated instructional copy across multiple AI, authentication,
database, functions, realtime, storage, and troubleshooting guides to
improve clarity and consistency.
* Replaced conversational phrasing (for example, “Let’s…/Let’s see…”)
with direct imperatives, tightened example lead-ins, and adjusted a few
step explanations for readability.
* Refreshed some tutorial text and code-sample presentation in guides
(no behavioral changes).
  * Added/adjusted minor MDX lint guidance in a couple of documents.
<!-- 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>
2026-06-17 11:24:59 -07:00

115 lines
4.4 KiB
Plaintext

---
id: 'timescaledb'
title: 'timescaledb: Time-Series data'
description: 'Scalable time-series data storage and analysis'
---
<Admonition type="deprecation">
The `timescaledb` extension is deprecated in projects using Postgres 17. It continues to be supported in projects using Postgres 15, but will need to dropped before those projects are upgraded to Postgres 17. See the [Upgrading to Postgres 17 notes](/docs/guides/platform/upgrading#upgrading-to-postgres-17) for more information.
If you are using hypertables, follow the [migration guide](/docs/guides/database/migrating-to-pg-partman) to convert to native partitioning managed by `pg_partman`.
For additional support, contact our Success team by creating a support ticket in the Supabase Dashboard.
</Admonition>
[`timescaledb`](https://docs.timescale.com/timescaledb/latest/) is a Postgres extension designed for improved handling of time-series data. It provides a scalable, high-performance solution for storing and querying time-series data on top of a standard Postgres database.
`timescaledb` uses a time-series-aware storage model and indexing techniques to improve performance of Postgres in working with time-series data. The extension divides data into chunks based on time intervals, allowing it to scale efficiently, especially for large data sets. The data is then compressed, optimized for write-heavy workloads, and partitioned for parallel processing. `timescaledb` also includes a set of functions, operators, and indexes that work with time-series data to reduce query times, and make data easier to work with.
<Admonition type="note">
Supabase projects come with [TimescaleDB Apache 2 Edition](https://docs.timescale.com/about/latest/timescaledb-editions/#timescaledb-apache-2-edition). Functionality only available under the Community Edition is not available.
</Admonition>
## Enable the extension
<Tabs
scrollable
size="small"
type="underlined"
defaultActiveId="dashboard"
queryGroup="database-method"
>
<TabPanel id="dashboard" label="Dashboard">
1. Go to the [Database](/dashboard/project/_/database/tables) page in the Dashboard.
2. Click on **Extensions** in the sidebar.
3. Search for `timescaledb` and enable the extension.
</TabPanel>
<TabPanel id="sql" label="SQL">
{/* prettier-ignore */}
```sql
-- Enable the "timescaledb" extension
create extension timescaledb with schema extensions;
-- Disable the "timescaledb" extension
drop extension if exists timescaledb;
```
</TabPanel>
</Tabs>
Even though the SQL code is `create extension`, this is the equivalent of "enabling the extension". To disable an extension you can call `drop extension`.
It's good practice to create the extension within a separate schema (like `extensions`) to keep your `public` schema clean.
## Usage
To demonstrate how `timescaledb` works, consider an example where we have a table that stores temperature data from different sensors. Create a table named "temperatures" and store data for two sensors.
First we create a hypertable, which is a virtual table that is partitioned into chunks based on time intervals. The hypertable acts as a proxy for the actual table and makes it easy to query and manage time-series data.
{/* prettier-ignore */}
```sql
create table temperatures (
time timestamptz not null,
sensor_id int not null,
temperature double precision not null
);
select create_hypertable('temperatures', 'time');
```
Next, we can populate some values
{/* prettier-ignore */}
```sql
insert into temperatures (time, sensor_id, temperature)
values
('2023-02-14 09:00:00', 1, 23.5),
('2023-02-14 09:00:00', 2, 21.2),
('2023-02-14 09:05:00', 1, 24.5),
('2023-02-14 09:05:00', 2, 22.3),
('2023-02-14 09:10:00', 1, 25.1),
('2023-02-14 09:10:00', 2, 23.9),
('2023-02-14 09:15:00', 1, 24.9),
('2023-02-14 09:15:00', 2, 22.7),
('2023-02-14 09:20:00', 1, 24.7),
('2023-02-14 09:20:00', 2, 23.5);
```
And finally we can query the table using `timescaledb`'s `time_bucket` function to divide the time-series into intervals of the specified size (in this case, 1 hour) averaging the `temperature` reading within each group.
{/* prettier-ignore */}
```sql
select
time_bucket('1 hour', time) AS hour,
avg(temperature) AS average_temperature
from
temperatures
where
sensor_id = 1
and time > NOW() - interval '1 hour'
group by
hour;
```
## Resources
- Official [`timescaledb` documentation](https://docs.timescale.com/timescaledb/latest/)