DEV Community: Yuri

Dev update - [March, 2026]

Yuri — Mon, 09 Mar 2026 19:28:02 +0000

Here’s everything that happened with Supabase in the last month:

Webinar: Ship Fast, Stay Safe

Learn how top agencies balance velocity with control when using AI coding tools to build production applications on Supabase.

Logs Drains on Pro

Log Drains are now available on Pro. Send your Postgres, Auth, Storage, Edge Functions, and Realtime logs to Datadog, Grafana Loki, Sentry, Axiom, S3, or your own endpoint.

Blog Post

Docs now export to Markdown for AI tools

Every guide on docs.supabase.com now has a "Copy as Markdown" option, plus direct links to ask ChatGPT and Claude. Copy any page into your agent or tool of choice with one click.

Docs

Storage: major performance and security overhaul

Object listing is up to 14.8x faster on 60M+ row datasets. The prefixes table and its 6 triggers are gone, replaced with a hybrid skip-scan algorithm and cursor-based pagination. Security fixes close a path traversal vulnerability and prevent orphan objects from direct SQL deletes.

Blog Post

Edge Functions dashboard for self-hosted and CLI

List and search your functions, view details, test directly from the dashboard, and download as .zip. No longer cloud-only.

Twitter

Multigres Postgres parser: 2.5x faster than the cgo alternative

Built in 8 weeks using Claude Code. A comparable MySQL parser took over a year.

Blog Post Twitter

Quick Product Announcements

⚠️ Action Required: OpenAPI spec access via anon key deprecated March 11. The /rest/v1/ schema endpoint will only be accessible via service role or secret API keys after this date. Existing data API usage is unaffected. GitHub
Observability Overview page is rolling out. Twitter
Table filters now use AI. Describe what you want to find and the dashboard applies the right Postgres filters. Available under Feature Previews. Twitter GitHub
Queue table operations in the Table Editor. Stage inserts, edits, and deletes, review in Diff View, then commit with cmd + s. Twitter
Supabase plugin for Cursor is live. Twitter
Copy AI prompts from the dashboard. The same prompts powering the Supabase AI Assistant are now exportable for use in your local agent or tool of choice. Twitter
Inline SQL Editor saves SQL Snippets. Create and update snippets from Studio. Share via git in the supabase/snippets folder. GitHub
Command Menu gets Create and Search shortcuts. Hit cmd + k to create tables, RLS policies, Edge Functions, and Storage buckets — or jump directly to an existing one. Twitter
Read replicas now managed from the database replication page. Rolling out gradually — if you manage read replicas, look in Database settings.
Receipt downloads now available. Download receipts from the Invoices section in your org billing page.

Made with Supabase

A purpose-built tool for running powerful affiliate and referral campaigns. Website
Supabase x YCombinator Hackathon winner: An AI Agent Personal Trainer Website
AI video production for professionals Website
Generate APA citation-ready references from a URL or DOI in seconds Website
SupaClaw - A basic version of OpenClaw but built entirely on Supabase built-in features GitHub

Community Highlights

Supabase is sponsoring Postgres Conference 2026. Deepthi and Sugu are speaking on Multigres: horizontal scalability and intelligent sharding for Postgres. April 21-23 in San Jose. Use code 2026_SUPABASE20 for 20% off. Register
Codepup AI launched Supabase integration. Build a complete web app with a real Supabase backend — auto-generated, tested, and fixed by AI in under 30 minutes. Blog Post
BKND joins Supabase. Dennis Senn, creator of BKND, is joining to build a Lite offering for agentic workloads. BKND stays open source. Blog Post
Hydra joins Supabase. Joe Sciarrino, co-creator of Hydra, is joining to build Supabase Warehouse: an open data warehouse architecture for developers. Hydra co-developed pg_duckdb, which accelerates analytics queries on Postgres by over 600x. Blog Post
Getting Started with Supabase - Official Guide YouTube
Supabase on Observable Flutter - Episode YouTube
Inside Supabase Edge Functions: How Serverless Magic Actually Works Blog
Unlocking Scalable Backend Development: Why Supabase and Node.js are Revolutionizing Modern Applications in 2026 Blog
Adding GitHub, Google, and X Login to Next.js 15 with Supabase Auth Blog

⚠️ Baking hot meme zone ⚠️

Build "Sign in with Your App" using Supabase Auth

Yuri — Wed, 24 Dec 2025 15:45:00 +0000

You've used "Sign in with Google" and "Sign in with GitHub" countless times. But what if your Supabase project could be the identity provider? Today, we're adding OAuth 2.1 and OpenID Connect server capabilities to Supabase Auth, turning your project into a full-fledged identity provider.

This opens up powerful new possibilities: AI agents authenticating through your app via the Model Context Protocol (MCP), third-party developers building on your platform, partner integrations accessing your APIs securely, and enterprise single sign-on. All using the same battle-tested auth infrastructure you already rely on.

Why We Built This

The immediate catalyst? Model Context Protocol (MCP) authentication. As AI agents and LLM tools become ubiquitous, they need a standardized way to authenticate with services. MCP has emerged as that standard, and it's built on OAuth 2.1. Your Supabase project can now be the identity provider these AI tools authenticate against.

But the applications extend far beyond AI:

Third-party developer ecosystems - Let partners build apps that integrate with your platform
Partner API access - Grant secure access to external services
"Powered by [Your App]" - Enable users to use their existing account on your platform to sign into partner applications
Enterprise SSO - Full OpenID Connect support with ID tokens, UserInfo endpoint, and organizational single sign-on

If you're building a platform where other developers or services need secure access to user data, OAuth 2.1 server capabilities are now baked into your Supabase project.

What You Can Build

With Supabase Auth as an OAuth 2.1 provider, you can:

For AI and Automation:

MCP servers that authenticate users through your Supabase project
AI agents that securely access user data with proper authorization
LLM tools integrated into your application ecosystem

For Developer Platforms:

Third-party apps offering "Sign in with [Your App]"
Partner integrations with granular access control
Developer API access with OAuth tokens
Marketplace apps built on your platform

For Enterprise:

OpenID Connect single sign-on (SSO) with ID tokens and UserInfo endpoint
Centralized identity management across services
Standards-compliant enterprise authentication
Compliance-friendly audit trails

How It Works: The Big Picture

Supabase Auth implements OAuth 2.1 with OpenID Connect (OIDC), the modern, secure standards for authentication and identity. At its core is the authorization code flow with PKCE (Proof Key for Code Exchange).

The implementation uses the authorization code flow, the most secure OAuth flow for server-side apps and native applications. PKCE protects against authorization code interception attacks. Access tokens are JWTs containing standard Supabase claims (user_id, role) plus OAuth-specific claims like client_id. For OpenID Connect flows, clients also receive ID tokens, standardized identity tokens with user profile information, and can access the UserInfo endpoint to retrieve user data. Refresh tokens enable long-lived sessions without re-authentication, while the JWKS endpoint provides public key infrastructure for third parties to validate tokens.

The best part? Your existing Supabase security model extends naturally to OAuth: Row Level Security (RLS) policies apply to OAuth access tokens just like they do to regular session tokens.

Works with Your Existing Auth Stack

One of the most powerful aspects of this implementation is how seamlessly it integrates with Supabase Auth features you're already using. When users authenticate through the OAuth flow, you can use all of Supabase Auth's existing methods: password authentication, magic links, social providers (Google, GitHub, etc.), multi-factor authentication (MFA), and phone authentication. Your third-party integrations get the benefit of your existing authentication security without you having to rebuild anything.

Already using Custom Access Token Hooks to add custom claims to user tokens? They work with OAuth tokens too. You can inject client-specific claims, add custom permissions, or implement any token customization logic you need. The flexibility you have with regular auth tokens extends to OAuth.

Your RLS policies automatically apply to OAuth access tokens. The tokens include the standard user_id and role claims you're used to, plus a client_id claim that identifies which OAuth client is making the request.

This means you can grant different OAuth clients access to different subsets of user data:

-- Grant your mobile app access to user profiles
CREATE POLICY "Mobile app can read profiles"
ON profiles FOR SELECT
USING (
  (auth.uid() = user_id)
  AND
  ((auth.jwt() ->> 'client_id') = 'mobile-app-client-id')
);

-- Grant a third-party analytics dashboard read-only access to metrics
CREATE POLICY "Analytics dashboard can read metrics"
ON user_metrics FOR SELECT
USING (
  (auth.uid() = user_id)
  AND
  ((auth.jwt() ->> 'client_id') = 'analytics-dashboard-client-id')
);

MCP Authentication

Supabase Auth fully complies with the Model Context Protocol's OAuth 2.1 authentication spec. Your Supabase project exposes standard OAuth authorization server metadata at /.well-known/oauth-authorization-server, enabling automatic discovery of your authorization endpoints, token endpoints, and capabilities. MCP clients can register themselves dynamically using OAuth 2.1 dynamic client registration (no manual configuration required).

Here's what this means in practice: point an MCP-compatible AI tool at your Supabase project's auth URL, and it handles the rest. The tool discovers your endpoints, registers itself as a client, initiates the OAuth flow, and obtains tokens. The AI agent authenticates as the user, with all your RLS policies enforced automatically. Users see your consent screen, approve access, and the AI tool operates on their behalf, with exactly the permissions you've defined. No passwords exposed, no custom API wrappers needed.

We're just getting started with MCP. We're working on making it even easier to build MCP servers directly in Supabase, bringing the same developer experience you love to AI agent integrations.

Getting Started

Setting up OAuth 2.1 in your Supabase project starts with registering OAuth clients through the Supabase dashboard or Management API. You'll configure their allowed redirect URIs and receive a client_id. Then you'll build your authorization flow, an endpoint that receives OAuth authorization requests, authenticates users (using existing Supabase Auth methods), presents a consent UI, and confirms approvals with Supabase Auth.

Update your Row Level Security policies to handle OAuth clients appropriately, deciding which data third-party apps can access and what remains user-only. Third-party apps validate tokens using your public JWKS endpoint, no shared secrets required. They can verify tokens asymmetrically using standard OAuth 2.1 libraries.

Complete documentation with code examples is available in our OAuth 2.1 guide.

OpenID Connect Support

Beyond OAuth 2.1, Supabase Auth now includes full OpenID Connect (OIDC) support, making it perfect for enterprise single sign-on and standardized identity integrations.

When authenticating with OIDC, clients receive an ID token alongside the access token. This standardized JWT contains user profile information and is signed by your Supabase project, allowing third parties to verify user identity without additional API calls. Your project also exposes the standard OIDC UserInfo endpoint, providing a secure way for clients to retrieve user profile information using their access token, enabling seamless integration with enterprise identity systems and standard OIDC libraries.

Your project automatically exposes an OIDC discovery endpoint at /.well-known/openid-configuration, making integration with enterprise tools and standard OIDC clients straightforward. Point an enterprise SSO system at your Supabase project, and it discovers everything it needs to integrate. This makes Supabase Auth a complete identity provider solution, compatible with any OIDC-compliant application or service.

What's Next

We're continuing to expand OAuth capabilities. Granular scopes are coming soon, allowing clients to request specific permissions rather than full user access (scope=read:profile read:metrics). We're making it even easier to build and deploy MCP servers directly in Supabase, bringing AI agent authentication into the same seamless developer experience you already know.

We're building this in the open. The GitHub discussion is active, share your use cases and help shape the roadmap.

Try It Today

OAuth 2.1 and OpenID Connect capabilities are now available in Supabase Auth. Get started:

Read the documentation
View the GitHub discussion
Join the Discord to share what you're building

Whether you're building an MCP server for AI agents, implementing enterprise SSO with OpenID Connect, creating a developer platform, or just want to offer "Sign in with [Your App]", Supabase Auth now has you covered.

The new Supabase power for Kiro

Yuri — Tue, 23 Dec 2025 14:18:00 +0000

We are announcing new Supabase powers for Amazon's Kiro IDE. With these powers, you can build full-stack applications faster by giving Kiro deep knowledge of your Supabase project, best practices for database migrations, edge functions, and security policies.

What are Kiro powers?

Kiro powers bundles MCP tools and steering files into a single install, giving your agent specialized knowledge without overwhelming it with context. Traditional MCP servers load all their tools into context immediately, overwhelming the agent. Powers load only when relevant.

When you install a Supabase power in Kiro, the AI assistant gets immediate access to:

Your Supabase database schema
Best practices for writing edge functions
Security guidelines for Row Level Security (RLS) policies
SQL syntax optimized for Postgres

What you can do with the Supabase powers

The Supabase powers connect Kiro to your Supabase projects and gives you one-click access to common development tasks. We're releasing two powers—one for developing on hosted projects, and one for developing with the local Supabase stack through Supabase CLI.

Manage database schemas
Kiro can read your database schema, suggest migrations, and help you structure tables following Postgres best practices. The powers uses Supabase's CLI and MCP server to understand your current schema and make informed suggestions about changes.

Review edge functions

Click a button and Kiro will review your edge functions for common issues, performance problems, and best practices. The powers includes specific guidance on how Supabase edge functions work, including the Deno runtime, environment variables, and local testing.

Check security and performance

The powers includes automations to check advisors that scan your local project for security issues and performance bottlenecks. Kiro can identify missing RLS policies, inefficient queries, and common security mistakes before you deploy.

Write better SQL

Kiro gets context-aware help for writing SQL that works well with Postgres. The powers include guidance on formatting queries, naming conventions, writing secure database functions, and structuring complex queries with CTEs. Kiro helps ensure your SQL follows Postgres standards and Supabase best practices.

How it works

Kiro powers use the Model Context Protocol (MCP) to connect AI assistants to external tools and knowledge. The Supabase power bundles:

MCP server configuration that connects to your hosted or local Supabase project
Steering files that tell Kiro how to use Supabase tools correctly
Manual triggers that give you one-click access to reviews and checks
Dynamic context that loads only when you're working on database, security, or edge function tasks

When you ask Kiro to help with a database migration or edge function, it automatically loads the right context without cluttering the conversation with unnecessary information. Kiro also unloads the context when the power is no longer needed.

Get started

To use the Supabase powers:

Install Kiro and add the Supabase power for local or hosted development
Ask Kiro to setup your Supabase project
Start building

Built on open standards

Kiro powers use the same Supabase MCP Server used by other AI coding assistants, ensuring that your app development experience in Kiro remains familiar to you.

We're committed to delivering a great Supabase development experience across every tool. These Kiro powers gives developers instant access to best practices, security checks, and deep platform knowledge without leaving their editor.

Try the Supabase powers today and let us know what you build.

Introducing Supabase ETL

Yuri — Mon, 22 Dec 2025 14:09:00 +0000

We're introducing Supabase ETL: a change-data-capture pipeline that replicates your Postgres tables to analytical destinations in near real time.

Supabase ETL reads changes from your Postgres database and writes them to external destinations. It uses logical replication to capture inserts, updates, deletes and truncates as they happen. Setup takes minutes in the Supabase Dashboard.

The first supported destinations are Analytics Buckets (powered by Iceberg) and BigQuery.

Supabase ETL is open source. You can find the code on GitHub at github.com/supabase/etl.

Why separate OLTP and OLAP?

Postgres is excellent for transactional workloads like reading a single user record or inserting an order. But when you need to scan millions of rows for analytics, Postgres slows down.

Column-oriented systems like BigQuery, or those built on open formats like Apache Iceberg, are designed for this. They can aggregate massive datasets orders of magnitude faster, compress data more efficiently, and handle complex analytical queries that would choke a transactional database.

Supabase ETL gives you the best of both worlds: keep your app fast on Postgres while unlocking powerful analytics on purpose-built systems.

How it works

Supabase ETL captures every change in your Postgres database and delivers it to your analytics destination in near real time.

Here's how:

You create a Postgres publication that defines which tables to replicate
You configure ETL to connect a publication to a destination
ETL reads changes from the publication through a logical replication slot
Changes are batched and written to your destination
Your data is available for querying in the destination

The pipeline starts with an initial copy of your selected tables, then switches to streaming mode. Your analytics stay fresh with latency measured in milliseconds to seconds.

Setting up ETL

You configure ETL entirely through the Supabase Dashboard.No code required.

Step 1: Create a publication

A publication defines which tables to replicate. You create it with SQL or via the UI:

-- Replicate specific tables
create publication analytics_pub
for table events, orders, users;

-- Or replicate all tables in a schema
create publication analytics_pub
for tables in schema public;

Step 2: Enable replication

Navigate to Database in your Supabase Dashboard. Select the Replication tab and click Enable Replication.

Step 3: Add a destination

Click Add Destination and choose your destination type.

Note: For Analytics Buckets, you will need to create an analytics bucket first in the Storage section.

Configure the destination with your bucket credentials and select your publication. Click Create and Start to begin replication.

Step 4: Monitor your pipeline

The Dashboard shows pipeline status and lag. You can start, stop, restart, or delete pipelines from the actions menu.

Available destinations

Our goal with Supabase ETL is to let you connect your existing data systems to Supabase. We're actively expanding the list of supported destinations. Right now, the official destinations are Analytics Buckets and BigQuery.

Analytics Buckets

Analytics Buckets are specialized storage buckets built on Apache Iceberg, an open table format designed for large analytical datasets. Your data is stored in Parquet files on S3.

When you replicate to Analytics Buckets, your tables are created with a changelog structure. Each row includes a cdc_operation column indicating whether the change was an INSERT, UPDATE, or DELETE. This append-only format preserves the complete history of all changes.

You can query Analytics Buckets from PyIceberg, Apache Spark, DuckDB, Amazon Athena, or any tool that supports the Iceberg REST Catalog API.

BigQuery

BigQuery is Google's serverless data warehouse, built for large-scale analytics. It handles petabytes of data and integrates well with existing BI tools and data pipelines.

When you replicate to BigQuery, Supabase ETL creates a view for each table and uses an underlying versioned table to support all operations efficiently. You query the view, and ETL handles the rest.

Adding and removing tables

You can modify which tables are replicated after your pipeline is running.

To add a table:

alter publication analytics_pub add table products;

To remove a table:

alter publication analytics_pub drop table orders;

After changing your publication, restart the pipeline from the Dashboard actions menu for the changes to take effect.

Note: ETL does not remove data from your destination when you remove a table from a publication. This is by design to prevent accidental data loss.

When to use ETL vs read replicas

Read replicas and ETL solve different problems.

Read replicas help when you need to scale concurrent queries, but they're still Postgres. They don't make analytics faster.

ETL moves your data to systems built for analytics. You get faster queries on large datasets, lower storage costs through compression, and complete separation between your production workload and analytics.

You can use both: read replicas for application read scaling, ETL for analytics.

Things to know

Replication with Supabase ETL has a few constraints to be aware of:

Tables must have primary keys (this is a Postgres logical replication requirement)
Generated columns are not supported
Custom data types are replicated as strings
Schema changes are not automatically propagated to destinations
Data is replicated as-is, without transformation
During the initial copy phase, changes accumulate in the WAL and are replayed once streaming begins

We're working on schema change support and additional destinations, and evaluating different streaming techniques to improve flexibility and performance.

Pricing

Supabase ETL is usage-based:

$25 per connector per month
$15 per GB of change data processed after the initial sync
Initial copy is free

Get started

Supabase ETL is in private alpha. To request access, contact your account manager or fill out the form in the Dashboard.

If you want to dive into the code, the ETL framework is open source and written in Rust. Check out the repository at github.com/supabase/etl.

Introducing Analytics Buckets

Yuri — Fri, 19 Dec 2025 14:45:00 +0000

Supabase is introducing Analytics Buckets, which you can use to store huge sets of data in Supabase Storage. Postgres is great for your app. But Postgres isn't designed for analytical workloads.

Analytics Buckets are a specialized storage type in Supabase designed for analytical workloads and built on Apache Iceberg and Amazon S3. They store data in columnar Parquet format, which is optimized for scans, aggregations, and time-series queries.

Think of them as cold storage for your data, with a query engine attached.

Your hot transactional data stays in Postgres. Your historical data and analytical workloads live in Analytics Buckets. You query both using familiar tools.

What do they do?

Analytics Buckets give you:

Cost-effective storage. S3 pricing instead of database storage. Documented savings of 30-90% on storage costs for large datasets.
Open table format. Apache Iceberg means no vendor lock-in. Query your data from any compatible tool.
Schema evolution. Change your table schema without rewriting data.
Time travel. Query historical snapshots of your data. See what a table looked like at any point in time.
Full audit history. Every change is preserved. Track what changed, when, and how.

When to use Analytics Buckets vs Postgres

Analytics Buckets and Postgres are complementary. They serve different workloads.

Keep data in Postgres when:

You need low-latency reads for your application
Data changes frequently and consistency matters
Your dataset is small to medium size
You need real-time access from your app

Use Analytics Buckets when:

You are storing millions or billions of rows
You run heavy analytical queries that scan large tables
You need long-term retention at low cost
You want to query data from multiple tools
You need complete audit history and time travel

Many teams use both. Keep the last 90 days in Postgres. Archive everything to Analytics Buckets. Query historical data when needed.

How they work

Analytics Buckets use Apache Iceberg, an open table format created for large analytical datasets. Here is what happens under the hood:

Data is stored in Parquet files on S3
Iceberg manages metadata including schema, partitions, and snapshots
An Iceberg REST Catalog provides the interface for querying
You connect using any Iceberg-compatible tool

The separation of compute and storage means you can scale each independently. Store petabytes of data and query only what you need.

Creating an Analytics Bucket

You can create an Analytics Bucket from the Dashboard or using the SDK.

Using the Dashboard

Navigate to Storage in your Supabase Dashboard
Click Create Bucket
Enter a name for your bucket
Select Analytics Bucket as the bucket type
Click Create

You can use the Supabase Dashboard to define columns and set data types, including complex types like decimal with precision and scale. The foreign data wrapper schema will automatically be configured for you. Once your table is created, you can manage Analytics Buckets in the same way that you manage your Postgres tables.

Using the SDK

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://your-project.supabase.co', 'your-service-key')

await supabase.storage.createBucket('my-analytics-bucket', {
  type: 'ANALYTICS',
})

Connecting to Analytics Buckets

Analytics Buckets require authentication with two services:

Iceberg REST Catalog manages metadata for your tables. It handles schema, partitions, and snapshots.

S3-Compatible Storage stores the actual data in Parquet format.

You authenticate using your Supabase service key for the catalog and S3 credentials for storage.

Streaming data with Supabase ETL

Analytics Buckets work hand in hand with Supabase ETL. ETL captures changes from your Postgres database and streams them to Analytics Buckets in near real time.

This gives you:

Automatic replication of your Postgres tables
Near real-time data in your analytics bucket
Complete changelog with every insert, update, and delete
No manual data movement or scheduled jobs

To set up replication, create a Postgres publication for the tables you want to replicate, then add an Analytics Buckets destination in the Replication section of the Dashboard.

Querying from Postgres

You can query Analytics Buckets directly from Postgres using Foreign Data Wrappers. This lets you join hot data in Postgres with historical data in Analytics Buckets.

-- Create a foreign server for your Iceberg data
create server iceberg_server
foreign data wrapper iceberg_wrapper
options (
    aws_access_key_id 'your-access-key',
    aws_secret_access_key 'your-secret-key',
    region_name 'us-east-1'
);

-- Import tables from your analytics bucket
import foreign schema "analytics"
from server iceberg_server
into iceberg;

-- Query historical data
select * from iceberg.events
where event_timestamp > '2024-01-01';

Data tiering pattern

A common architecture is data tiering: keeping recent data in Postgres and archiving history to Analytics Buckets.

Partition tables by time in Postgres, keeping a rolling window like the last 90 days
Stream all data to Analytics Buckets using Supabase ETL
Drop old partitions from Postgres
Query recent data from Postgres, historical data from Analytics Buckets

This keeps your Postgres database small and fast. Storage costs drop. Analytics queries run on data optimized for scans.

Compatible tools

Analytics Buckets work with any tool that supports the Iceberg REST Catalog API:

PyIceberg
Apache Spark
DuckDB
Amazon Athena
Trino
Apache Flink
Snowflake (via external tables)
BigQuery (via BigLake)

Pricing and availability

Analytics Buckets are free during the Private Alpha. Standard egress charges apply when you move data out of the region.

To request access, fill out the form at forms.supabase.com/analytics-buckets.

Get started

Request access to the Private Alpha
Create an Analytics Bucket in the Dashboard
Connect using PyIceberg, Spark, or your tool of choice
Set up ETL to stream data from Postgres automatically

Separate your transactional and analytical workloads. Keep Postgres fast. Store history at S3 prices. Query from any tool.

We are excited to see what you build.

Introducing Vector Buckets

Yuri — Thu, 18 Dec 2025 17:30:51 +0000

We're introducing Vector Buckets, a new storage option that gives you the durability and cost efficiency of Amazon S3 with built-in similarity search.

Vector search is becoming a core primitive for modern apps: semantic search, recommendations, RAG, image and audio similarity, and more.

Supabase already gives you powerful tools for vectors, such as pgvector in Postgres. With Vector Buckets, you now have more options for how you store vectors:

Use pgvector for smaller, latency-sensitive datasets that belong tightly in your database.
Use Vector Buckets when you need to store a large amount of vectors—up to tens of millions—on a durable storage layer with similarity search built in.

What are Vector Buckets?

Vector Buckets are a new bucket type in Supabase Storage.

Conceptually:

A Vector Bucket is where your vector indexes live.
Inside each bucket, you define one or more vector indexes (for example: documents-openai).
Each index stores high-dimensional vectors plus optional metadata.
You query those indexes using Supabase clients or directly from Postgres via a foreign data wrapper.

What do Vector Buckets bring to the table?

Scalable vector storage for large datasets

Embeddings add up quickly: thousands of floats per vector, multiplied by millions of items.

Instead of putting everything in Postgres, Vector Buckets store your embeddings in S3-backed object storage, which gives you:

Capacity for tens of millions of vectors per index
A storage layer designed for large, durable datasets
Room to keep full archives of vectors without over-optimising your Postgres schema or worrying about table bloat
Your vectors live in a storage layer built for large datasets, while you still query them through Postgres.

Built-in similarity search

Vector Buckets are not just blobs of float arrays. Each index supports similarity search out of the box.

Similarity search lets you find items that are conceptually related based on their vector representations, not just exact keyword matches. That’s what powers:

Semantic document search (“find content about this topic, even if the keywords differ”)
Product and content recommendations (“find items similar to this one”)
Image, audio, or video similarity (“find assets that look or sound like this”)
De-duplication and near-duplicate detection across large media libraries

With Vector Buckets, you can:

Insert vectors with a key, a float32 vector, and metadata
Run k-NN queries (for example, “return the 20 closest vectors to this embedding”)
Use a familiar distance metric such as cosine similarity
Ask for distances and metadata along with the results

No extra vector database to run, no new query language. Just vector indexes with search, available from the same Supabase SDKs you already use or directly via Postgres.

Performance that fits most app workflows

Vector Buckets are designed to provide sub-second similarity search over large datasets, which is more than enough for:

Backend workflows and batch processing
AI agents and background jobs
Dashboards and internal tools
Many user-facing features where “fast” means hundreds of milliseconds, not single-digit milliseconds

If you’re chasing ultra-low latency at very high QPS, pgvector in a tuned Postgres cluster (or a dedicated vector database) remains the best place to push performance. Vector Buckets focus on simple, scalable similarity search at large scale, not on being the absolute fastest option.

Metadata filtering

Each vector can include an arbitrary metadata object, for example:

metadata: {
  title: 'Getting started with Vector Buckets',
  type: 'doc',
  language: 'en',
  project_id: '1234',
}

You can:

Filter by metadata during similarity search (e.g. type = 'doc' AND language = 'en')
Query through Postgres and join the results with your relational tables
Build multi-tenant or multi-project search just by encoding tenant/project IDs into metadata
This makes it easy to build domain-aware, tenant-aware semantic search.

When should you use Vector Buckets vs `pgvector`?

Vector Buckets and pgvector are complementary. They serve different roles and work best together.

Use pgvector when…

You’re optimizing for lowest possible latency on user-facing queries
Vectors are part of your core relational model (for example, a column on documents or products)
You want transactional guarantees (data and embeddings written together)
Your vector dataset is small to medium and you’re comfortable scaling Postgres specifically for vector workloads

Use Vector Buckets when…

You want S3-style durability and scale for embeddings
You’re dealing with a large amount of vectors (up to tens of millions) that you don’t want sitting in Postgres
You’re building AI-heavy Supabase apps (semantic search, recommendations, RAG, media similarity) and want a managed vector storage tier
You prefer a clear split between:
Hot vectors in pgvector for the highest-traffic / most latency-sensitive queries
Warm or cold vectors in Vector Buckets for everything else

In practice, many apps will use both:

Keep your most frequently queried vectors (for example, current content, top products) in pgvector.
Store the full archive (older content, long tail SKUs, historical embeddings, large media corpora) in Vector Buckets.

How do Vector Buckets work?

At a high level, here’s what happens under the hood:

1. Vector Bucket in Supabase Storage

You create a bucket of type Vector Bucket in the Dashboard or via API.

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://your-project.supabase.co', 'your-service-key')

await supabase.storage.vectors.createBucket('embeddings')

2. Create Vector indexes inside the bucket

Inside the Vector Bucket, you create one or more indexes.

// Create an index in that bucket
await supabase.storage.vectors.from('embeddings').createIndex('documents-openai', {
  dimension: 1536,
  distanceMetric: 'cosine',
})

3. Store vectors

You can store vectors directly from the SDK, an Edge Function, or Postgres.

// Postgres
INSERT INTO s3_vectors.documents_openai (key, data, metadata)
VALUES
  (
    'doc-1',
    '[0.1, 0.2, 0.3, /* ... rest of embedding ... */]'::embd,
    '{"title": "Getting Started with Vector Buckets", "source": "documentation"}'::jsonb
  ),
  (
    'doc-2',
    '[0.4, 0.5, 0.6, /* ... rest of embedding ... */]'::embd,
    '{"title": "Advanced Vector Search", "source": "blog"}'::jsonb
  );

// JS-SDK (server only)
const index = supabase.storage.vectors
  .from('embeddings')
  .index('documents-openai')

const { error } = await index.putVectors({
  vectors: [
    {
      key: 'doc-1',
      data: {
        float32: [0.1, 0.2, 0.3 /* ... */],
      },
      metadata: {
        title: 'Getting started with Vector Buckets',
        type: 'doc',
        language: 'en',
      },
    },
  ],
})

4. Query vectors

You can run similarity search queries against your indexes, either via the SDK or Postgres.

// Postgres
SELECT
  key,
  metadata->>'title' as title,
  embd_distance(data) as distance
FROM s3_vectors.documents_openai
WHERE data <==> '[0.1, 0.2, 0.3, /* ... embedding ... */]'::embd
ORDER BY embd_distance(data) ASC
LIMIT 5;

// JS-SDK (Server only)
const index = supabase.storage.vectors
  .from('embeddings')
  .index('documents-openai')

// Query with a vector embedding
const { data, error } = await index.queryVectors({
  queryVector: {
    float32: [0.1, 0.2, 0.3 /* ... embedding of 1536 dimensions ... */],
  },
  topK: 5,
  returnDistance: true,
  returnMetadata: true,
})

Designed for workloads up to tens of millions of vectors

Vector Buckets currently can handle large-but-not-infinite workloads:

Each vector index supports up to tens of millions of vectors (50M per index today).
You can create multiple indexes per bucket (for tenants, models, or domains).

That makes Vector Buckets a great fit for:

Multi-tenant SaaS apps
Documentation and content libraries
Product catalogues and recommendation systems
Media libraries and image/video/audio similarity search
AI builders who want semantic search without running their own vector infrastructure

Example scenarios

A few concrete ways to put Vector Buckets to work:

1.AI documentation search

Store all your documentation (including old versions, drafts, and translations) as embeddings in a Vector Bucket.
Keep the most recent / highest-traffic docs in pgvector for instant in-app search.
Implement a search endpoint that queries pgvector first and falls back to Vector Buckets when needed.

2.Long-tail product search and recommendations

Vectorise your entire catalogue and store it in a Vector Bucket.
Include metadata for category, brand, stock status, and region.
Use metadata filters to refine search (e.g. “in stock, in this region, same category”).
Let recommendation jobs and AI agents work against the full set of products without bloating Postgres.

3.Media similarity and de-duplication

Store embeddings for images, audio or video frames in a Vector Bucket.
Use similarity search to:
Find visually similar assets for content discovery or recommendations
Detect possible copyright issues by finding near-duplicate content
Clean up your library by removing duplicate or near-duplicate media

Availability

Vector Buckets are currently available in Public Alpha for Pro projects and above.

Currently supported in the following regions:

us-east-1
us-east-2
us-west-2
eu-central-1
ap-southeast-2

More regions will be added in the near future.

We’re using this phase to refine the APIs, scaling behaviour, and search experience based on real workloads. Limits may evolve as we learn from how you use the feature in production.

Vector Buckets are free to use (fair use policy applies) during Public Alpha. Egress costs still apply.

Get started

You can try Vector Buckets in your project today:

1.Create a Vector Bucket

Dashboard → Storage → Create bucket → Vector Bucket.

2.Create an index

Pick a dimension that matches your embedding model and choose a distance metric.

3.Store vectors

Use Supabase clients to upsert vectors with metadata.

4.Query vectors

Build endpoints for semantic search, recommendations, or retrieval-augmented generation.

5.Layer with pgvector

Keep your hottest, most latency-sensitive vectors in pgvector, and store large archives and media-heavy datasets in Vector Buckets.

We’re excited to see what you build with this new vector storage tier.

As you try Vector Buckets during the Public Alpha, please send feedback—what works, what’s confusing, and what you’d like to see next will directly shape where we take this feature.

Top 10 Launches of Launch Week 15

Yuri — Fri, 18 Jul 2025 22:40:00 +0000

Here are the top 10 launches from the past week. They're all very exciting so make sure to check out every single one.

#1: New API Keys + JWT Signing Keys

Supabase Platform released new API keys, Publishable and Secret, and Supabase Auth now supports asymmetric JWTs with Elliptic Curve and RSA cryptographic algorithms. These changes improve the performance, reliability, and security of your Supabase projects.

#2: Analytics Buckets with Apache Iceberg Support

We launched Supabase Analytics Buckets in Private Alpha—storage buckets optimized for analytics with built-in support for Apache Iceberg. We’ve coupled this with the new Supabase Iceberg Wrapper to make it easier for you to query your analytical data.

#3: OpenTelemetry Support

We’ve added support for OpenTelementry (OTel) across our services so you can soon send logs, metrics, and traces to any OTel-compatible tooling. We’ve also unified logs under a single interface in our Dashboard as well as added new capabilities to our AI Assistant to improve the debugging experience.

#4: Build with Figma Make and Supabase

We’ve partnered with Figma so you can hook up a Supabase backend to your Figma Make project, enabling you to persist data and tap into the suite of Supabase products to help you build prototypes quickly and scale them when you gain traction.

#5: Storage: 500 GB Uploads and Cheaper Cached Egress

You can now upload files as large as 500 GB (up from 50 GB), enjoy much cheaper cached egress pricing at $0.03/GB (down from 0.09/GB), and increased egress quota that doubles your egress before you have to start paying.

#6: Edge Functions: Deno 2, 97% Faster Boot Times, and Persistent File Storage

Edge Functions now support Deno 2.1, persistent file storage so you can mount any S3-compatible storage and read and write to them inside of your functions, up to 97% faster boot times, and support for Deno’s Sync APIs.

#7: Branching 2.0: GitHub Optional

You can now spin up, view diffs, and merge your branches directly from the Supabase Dashboard without having to connect to GitHub.

#8: Supabase UI: Platform Kit

We’ve built out several UI components to make it easy for you to feature the core of Supabase Dashboard inside your own app so you or your users can interact with Supabase projects natively with a customizable interface.

#9: Stripe-To-Postgres Sync Engine as an NPM Package

Now you can conveniently sync your Stripe data to your Supabase database by importing the npm package @supabase/stripe-sync-engine, whether in your Node.js app or even deploying it in a Supabase Edge Function.

#10: Algolia Connector for Supabase

We’ve been collaborating closely with Algolia to bring you a connector for Supabase so you can easily index your data and enable world class search experiences.

Launch Week Continues

There's always more activities for you to get involved with:

Launch Week 15: Meetups

Our community is hosting more meetups around the world. This is your chance to engage with others building with Supabase in a city near you.

See events

Launch Week 15: Hackathon

We've got another hackathon that you wouldn't want to miss! Now's your chance to vibe code something amazing, show it off to the community, and win some limited edition Supabase swag.

Supabase Launch Week 15 Hackathon

Yuri — Fri, 18 Jul 2025 19:11:00 +0000

We have just concluded Launch Week 15 with so many new updates, but no launch week is complete without a hackathon! The Supabase Launch Week 15 Hackathon begins now! Open your favorite IDE or AI agent and start building!

⚡️ More on Launch Week

As of the time of publishing this blog post, the hackathon has begun and will conclude on Sunday, July 27th, at 11:59 pm PT. You could win an extremely limited edition Supabase swag and add your name to the Supabase Hackathon Hall of Fame.

For some inspiration, check out all the winners from previous hackathons.

This is the perfect excuse to "Build in a weekend, scale to millions.” Since you retain all the rights to your submissions, you can use the hackathon as a launch pad for your new Startup ideas, side projects, or indie hacks.

Key Facts

You have 10 days to build a new o*pen-source* project using Supabase in some capacity
- Starting 10:00 am PT Friday, July 18th, 2025
- The submission deadline is 11:59 pm Sunday, midnight PT, July 27th, 2025
Enter as an individual or as a team of up to 4 people
Build whatever you want - a project, app, tool, or library. Anything.
1-minute video containing the following:
- Name of the project
- Demonstration of the project
- How Supabase is used within the project
Here is an example video. We do not assess the quality of the video itself. Remember to keep it concise.

Prizes

There are 5 categories, and there will be prizes for:

Best overall project
Best use of AI
Most fun / best easter egg
Most technically impressive
Most visually pleasing

There will be a winner and a runner-up prize for each category. Every team member on winning/runner-up teams gets a Supabase Launch Week swag kit, and the winner of the best overall project will get this cool mechanical keyboard as well!

Submission

You should submit your project from the submission form before 11:59 pm Sunday midnight PT, July 27th, 2025. The submission form will be put up here on this article before the deadline. Come back in about a week to find it!

Judges

The Supabase team will judge the winners for each category.
We will be looking for:

Creativity/inventiveness
Functions correctly/smoothly
Visually pleasing
Technically impressive
Use of Supabase features
FUN! 😃

Rules

Team size 1-4 (all team members on winning teams will receive a prize)
You cannot be on multiple teams
One submission per team
It's not a requirement to use AI
All design elements, code, etc., for your project must be created during the event
- Using frameworks/ libraries is fine
All entries must be Open Source (link to source code required in entry)
Must use Supabase in some capacity
Can be any language or framework
You must submit before the deadline (no late entries)
Include a link to a 1-minute demo video

Additional Info

Any intellectual property developed during the hackathon will belong to the team that developed it. We expect that each team will have an agreement between themselves regarding the IP, but this is not required.
By making a submission, you grant Supabase permission to use screenshots, code snippets, and/or links to your project or content of your README on our Twitter, blog, website, email updates, and in the Supabase discord server. Supabase does not make any claims over your IP.

Launch Week 15

Main Stage

Day 1 - Introducing JWT Signing Keys
Day 2 - Introducing Supabase Analytics Buckets with Iceberg Support
Day 3 - Introducing Branching 2.0
Day 4 - Introducing New Observability Features in Supabase
Day 5 - Introducing Persistent Storage for Edge Functions

Build Stage

Worldwide Community Meetups

Storage: 10x Larger Uploads, 3x Cheaper Cached Egress, and 2x Egress Quota

Yuri — Fri, 18 Jul 2025 17:58:27 +0000

⚡️ More on Launch Week

We're very excited to announce Supabase Storage is getting better for everyone. We are:

Increasing the maximum file size to 500 GB, up from 50 GB
Reducing egress costs for requests cached by our API Gateway is charged at $0.03/GB, down from $0.09/GB
Free plans get 5 GB of cached egress in addition to 5 GB of uncached egress. All paid plans get 250 GB of cached egress and 250 GB of uncached egress, bundled in.

The 500 GB limit for individual files is available for all paid plans starting next week. Lower cached egress pricing and increased quotas for cached egress will be rolling out gradually to all users over the next few weeks and will take effect at the end of your current billing cycle. This should be a price reduction for all users for Storage.

10x Larger Uploads

Our community has asked for better support for increasingly large files, from high resolution video platforms and media heavy applications to SaaS platforms handling user generated data, storing 3D models and data archival.

We have made several optimizations to our platform infrastructure and API gateway to ensure reliable handling of very large files, allowing us to increase the limit from 50 GB to 500 GB for all paid plans.

Once it's released next week, you can take advantage of this feature by setting the new upload size limit here and use the new storage-specific hostname for your uploads. You can do this by adding storage after your project ref in the standard Supabase url. Replace project-ref.supabase.co with project-ref.storage.supabase.co. The older URL format will continue to work.

For uploading large files, we recommend using one of our multipart upload options:

Resumable uploads using TUS - Perfect for cases where network interruptions might occur, allowing uploads to resume from where they left off
S3 protocol multipart uploads - Ideal for applications that need S3-compatible upload workflows

Both approaches automatically handle breaking large files into manageable chunks during upload while presenting them as single objects for download.

3x Cheaper Cached Egress

All Supabase traffic flows through our API Gateway, which also functions as a content delivery network (CDN). When an asset is cached at the edge (and frequently accessed storage objects typically are), the CDN delivers it immediately. If it isn't cached, the request is forwarded to the region hosting your Supabase project before returning to the user.

Initially, we leaned towards keeping our pricing model simple instead of reflecting regional and cache-status variations in egress costs. This unfortunately meant that customers with very high cached storage bandwidth couldn't benefit from our lower cached egress rates.

Today, we are introducing a new pricing line item and are able to offer cached egress at a much lower rate of $0.03/GB. Combined with the Smart CDN for storage, which increases the cache hit rate for storage significantly, this would significantly reduce egress bill for our largest storage users.

2x Egress Quota

Paid plans previously included 250 GB of unified egress. We've now split that into 250 GB of cached egress and 250 GB of uncached egress, so customers with high cache hit rates effectively get twice the free egress. Free plans now include 5 GB of cached egress alongside 5 GB of uncached egress.

What Will You Build?

Check out Analytics Buckets, the other Storage launch this launch week, and how we built persistent file storage for edge functions with Storage here.

If you have any requests for improving Supabase Storage, let us know!

Launch Week 15

Main Stage

Build Stage

Supabase Launch Week 15 Hackathon

Worldwide Community Meetups

Persistent Storage and 97% Faster Cold Starts for Edge Functions

Yuri — Fri, 18 Jul 2025 15:30:10 +0000

Today, we are introducing Persistent Storage and up to 97% faster cold start times for Edge Functions. Previously, Edge Functions only supported ephemeral file storage by writing to /tmp directory. Many common libraries for performing tasks, such as zipping/unzipping files and image transformations, are built to work with persistent file storage, so making them work with Edge Functions required extra steps.

⚡️ More on Launch Week

The persistent storage option is built on top of the S3 protocol. It allows you to mount any S3-compatible bucket, including Supabase Storage Buckets, as a directory for your Edge Functions. You can perform operations such as reading and writing files to the mounted buckets as you would in a POSIX file system.

// read from S3 bucket
const data = await Deno.readFile('/s3/my-bucket/results.csv')

// make a directory
await Deno.mkdir('/s3/my-bucket/sub-dir')

// write to S3 bucket
await Deno.writeTextFile('/s3/my-bucket/demo.txt', 'hello world')

How to configure

To access an S3 bucket from Edge Functions, you must set the following as environment variables in Edge Function Secrets.

S3FS_ENDPOINT_URL
S3FS_REGION
S3FS_ACCESS_KEY_ID
S3FS_SECRET_ACCESS_KEY

If you are using Supabase Storage, follow this guide to enable and create an access key and id.

Use Case: SQLite in Edge Functions

The S3 File System simplifies workflows that involve reading and transforming data stored in an S3 bucket.

For example, imagine you are building an IoT app where a device backs up its SQLite database to S3. You can set up a scheduled Edge Function to read this data and then push the data to your primary Postgres database for aggregates and reporting.

// Following example is simplified for readability

import { DB } from "https://deno.land/x/sqlite@v3.9.1/mod.ts";
import { supabase } from '../shared/client.ts'

const today = new Date().toISOString().split('T')[0]
const backupDBPath = `backups/backup-${today}.db`

// Use S3 FS to read the Sqlite DB
const data = Deno.readFileSync(`/s3/${backupDBPath}`);

// Create an in-memory SQLite from the data downloaded from S3
// This is faster than directly reading from S3
const db = new DB();
db.deserialize(data);

function calculateStats(rows: IoTData[], date: string): StatsSummary {
  // ....
}

Deno.serve(async (req)=>{
  // Assuming IoT data is stored in a table called 'sensor_data'
  const rows = db.queryEntries<IoTData>(`
    SELECT * FROM sensor_data
    WHERE date(timestamp) = date('now', 'localtime')
  `)

  // Calculate statistics
  const stats = calculateStats(rows, today)

 // Insert stats into Supabase
 const { data, error } = await supabase
    .from('iot_daily_stats')
    .insert([stats])

  return new Response("OK);
});

97% Faster Function Boot Times, Even Under Load

Previously, Edge Functions with large dependencies or doing preparation work at the start (e.g., parsing/loading configs, initializing AI models) would incur a noticeable boot delay. Sometimes, these slow neighbors can impact other functions running on the same machine. All JavaScript workers in the Supabase Edge Functions Runtime were cooperatively scheduled on the same Tokio thread pool. If one worker had heavy startup logic, such as parsing JavaScript modules or running synchronous operations, it could delay every worker scheduled after. This led to occasional long‑tail latency spikes in high-traffic projects.
To address this issue, we moved workers which are still performing initial script evaluation onto a dedicated blocking pool. This approach prevents heavy initialization tasks from blocking the Tokio thread, significantly reducing boot time spikes for other functions.

The result

Boot times are now more predictable and wait times for cold starts are now much faster. Here’s a result of a benchmark we did to compare boot times before and after these changes.

Metric	Before	After	(Delta)
Avg	870 ms	42 ms	95 %
P95	8,502 ms	86 ms	99 %
P99	15,069 ms	460 ms	97 %
Worst	24,300 ms	1 630 ms	93 %
Spikes > 1 s	47 %	4 %	43 pp

Support for Synchronous APIs

By offloading expensive compute at function boot time onto a separate pool, we were able to enable the use of synchronous File APIs during function boot time. Some libraries only support synchronous File APIs (eg, SQLite), and this would allow you to set them up on Edge Functions before it starts processing requests.
You can now safely use the following synchronous Deno APIs (and their Node counterparts) during initial script evaluation:

Deno.statSync
Deno.removeSync
Deno.writeFileSync
Deno.writeTextFileSync
Deno.readFileSync
Deno.readTextFileSync
Deno.mkdirSync
Deno.makeTempDirSync
Deno.readDirSync

Keep in mind that the sync APIs are available only during initial script evaluation and aren’t supported in callbacks like HTTP handlers or setTimeout.

Deno.statSync('...') // ✅

setTimeout(() => {
  Deno.statSync('...') // 💣 ERROR! Deno.statSync is blocklisted on the current context
})

Deno.serve(() => {
  Deno.statSync('...') // 💣 ERROR! Deno.statSync is blocklisted on the current context
})

Try it on Preview Today

These changes will be rolled out along with the Deno 2 upgrade to all clusters within the next 2 weeks. Meanwhile, you can use the Preview cluster if you'd like to try them out today. Please see this guide on how to test your functions in Preview cluster.

Launch Week 15

Main Stage

Build Stage

Worldwide Community Meetups

Algolia Connector for Supabase

Yuri — Thu, 17 Jul 2025 19:25:33 +0000

Today, Algolia is launching a new Supabase Connector, making it easier than ever to index your Postgres data and power world-class search experiences without writing a single line of code.

With just a few clicks, you can connect your Supabase database to Algolia, select the tables you want to sync, and configure how often the data updates. Algolia handles the rest. You get a fast, reliable, scalable search index, and your team gets to focus on building.

⚡️ More on Launch Week

Partners Integrating with Supabase

Supabase is more than a backend. It is a growing ecosystem of tools that work well together so developers can build faster, scale more easily, and stay focused on their product.

Partners like Algolia bring best-in-class functionality (in Algolia’s case, fast and flexible search) directly into the Supabase workflow. For developers, that means fewer workarounds, no glue code, and a smoother path from idea to production.

For partners, integrating with Supabase means more than technical compatibility. It means product visibility to tens of thousands of active projects. Supabase regularly features integrations in our docs, Launch Weeks, blog, and community programs. Developers discover and adopt your product in the context where they’re already building.

Read on to see how the Algolia Connector for Supabase works.

How to use Algolia Connector for Supabase

To get started with Algolia’s connector, prepare the data in your Supabase database, create Supabase as a source in Algolia’s dashboard, set up your Algolia index and configure your sync job. Here’s how you can get started in just a few minutes.

1. Prepare your data in Supabase

Before you connect to Algolia, you will want to ensure all the fields you want to make searchable are in one place. If the fields you want to index live in more than one table, you can stitch them together in a Postgres View, allowing Algolia’s connector to get all the data you want to index.

For example, imagine you’re creating an app that allows you to easily find a movie to watch. You want to search across movie titles, genres, rating and actors. However, movies and actors are in two separate tables. You can create a view (e.g., movies_view) that combines the columns you need:

create view movies_view as
  select
    m.id as objectID, -- Algolia’s unique key
    m.title,
    array_agg(distinct c.actor_name) as actor_name,
    m.genre,
    m.rating,
    m.vote_count
  from
    movies as m
    left join movie_cast as c on c.movie_id = m.id
  group by m.id, m.title, m.rating, m.vote_count;

Later in the Algolia dashboard, you will be able to pick exactly which columns you want to index.

2. Go to Algolia dashboard

In Algolia, go to Data Sources → Connectors
Find "Supabase" in the list and click Connect

3. Configure your data source

First, you will need to fill in your Supabase connection info. From the Supabase dashboard:

Click the Connect button found in the top of our header
Scroll down to Connection Info → Transaction Pooler and copy host, port, database name, and username
Paste the database credentials into the Algolia setup screen
Enter your Supabase database password
Select your schema (usually public)
Give your source a name like supabase_movies
Algolia will check the connection and confirm your credentials

4. Configure your destination

Once you create Supabase as a data source, you'll need to tell Algolia where to index your data.

Select an existing or create a new Algolia index (e.g. supabase_movies_index)
Add Index Credentials to this destination by clicking Create one for me
Click Create destination

5. Configure your task and run your sync job

Choose how often you want it to sync your data (e.g. every 6 hours)
Pick whether to do full syncs or partial updates
Select the table or view you want to index. We recommend selecting only one table or view for each index
Choose your objectID (usually your primary key)

Once configured, create the task. Algolia will start syncing records from Supabase into your search index (in the YouTube demo above, 8,800+ movie records were synced in under a minute).

You can now instantly search your Supabase data using Algolia's lightning-fast API.

No more data pipelines. Just fast search.

With the Algolia + Supabase connector, you don’t need to build or maintain custom data pipelines. With Algolia, you don’t need to worry about scaling your own search infrastructure. With Algolia’s API clients, you just connect and go.

Getting Started

Launch Week 15

Main Stage

Day 1 - Introducing JWT Signing Keys
Day 2 - Introducing Supabase Analytics Buckets with Iceberg Support
Day 3 - Introducing Branching 2.0
Day 4 - Introducing New Observability Features in Supabase

Build Stage

Worldwide Community Meetups

New Observability Features in Supabase

Yuri — Thu, 17 Jul 2025 14:37:34 +0000

We are starting to add OpenTelemetry support to all our core products and our Telemetry server. OpenTelemetry (OTel) standardizes logs, metrics, and traces in a vendor-agnostic format, so you can ingest data into tools like Datadog, Honeycomb, or any monitoring solution you already use. While you'll still have the freedom to bring your own observability stack, we're preparing to surface this data natively in the Supabase dashboard.

⚡️ More on Launch Week

Today we are launching

Preview of our new logging Interface
Advanced Product Reports
Supabase AI Assistant with debugging capabilities

These updates mark the first step toward unified, end-to-end observability. You won't get the full OTel visualization just yet, but with these foundations in place, you'll soon be able to trace, analyze errors and performance issues, and troubleshoot your entire stack without leaving Supabase.

New logging Interface

Supabase is a collection of seamlessly integrated services. Storage talks to Postgres via the dedicated connection pooler. Edge Functions can talk to Auth and Realtime. If storage uploads fail, you must determine whether the problem lies with the storage server, the dedicated connection pooler, or the database. Until now, pinpointing the root cause meant jumping between multiple log streams.

Starting today, there is one interleaved stream of logs across all services. You can trace a single request across the entire Supabase stack. No more jumping between tabs to diagnose errors.

We have also added contextual log views. You can now jump from a function's invocation log directly into its execution logs. What used to require two disconnected sources is now stitched together in one view.

The new interface also supports filtering logs by the request status code, method, path, log level and the auth user associated with the request. This means you can quickly find all Postgrest 500 errors, or all requests made by a specific user with a few clicks.

Shoutout to openstatus.dev for providing the inspiration for some of our Log components.

The new logging interface is available as a feature preview today, which you can enable from the dashboard here. The new interface currently supports API Gateway logs and Postgres logs, with logs for the other products coming soon.

Advanced Product Reports

Apart from making our logs better, we also revamped the metrics exposed in our product reports. Previously, you had to host your own Grafana dashboard to access some of these advanced metrics. We are bringing some of these metrics directly into the dashboard, so that you can access them without any additional setup or maintaining your own production ready monitoring infrastructure.

Each product has its own dedicated report with a common set of metrics like number of requests, egress, and response time, along with product specific metrics like “Realtime connected clients”.

Additionally, you can drill into a specific time frame and filter by various request and response parameters across all reports.

Free users get a basic set of metrics for all products, while some of the advanced metrics (like p99 response time) is available for all paid customers.

Try out the new reports here.

Supabase AI Assistant with debugging capabilities

The Supabase AI Assistant now offers powerful new debugging capabilities, making it easier to identify and resolve issues across your stack.

You can now ask the Assistant to:

Retrieve logs for any Supabase product
Analyze log volume over time to identify spikes
Drill into specific time windows to investigate anomalies

This means you can go from "something looks off" to concrete answers, without leaving the chat.

The Assistant also comes with several quality-of-life upgrades:

Automatic chat renaming based on your queries
Branch diff reviews, perfect for projects using branching environments
A more capable model with additional controls for data privacy and security improvements built in

It's the fastest way to get answers for your project, whether you're debugging a failing function, reviewing changes between branches, or just trying to understand how your app is behaving in production.

This is an example of how the Assistant can analyze logs to identify issues:

It can also provide recommendations for fixes:

What's next

We'll keep adding more metrics across our reports
We're adding logs from the remaining products to new logging interface
We plan to make the new logging interface the default experience for all projects soon
Expose OpenTelemetry trace information in the logging interface

Launch Week 15

Main Stage

Day 1 - Introducing JWT Signing Keys
Day 2 - Introducing Supabase Analytics Buckets with Iceberg Support
Day 3 - Introducing Branching 2.0
Day 4 - Introducing New Observability Features in Supabase

Build Stage

Worldwide Community Meetups

DEV Community: Yuri

Dev update - [March, 2026]

Webinar: Ship Fast, Stay Safe

Logs Drains on Pro

Docs now export to Markdown for AI tools

Storage: major performance and security overhaul

Edge Functions dashboard for self-hosted and CLI

Multigres Postgres parser: 2.5x faster than the cgo alternative

Quick Product Announcements

Made with Supabase

Community Highlights

Build "Sign in with Your App" using Supabase Auth

Why We Built This

What You Can Build

How It Works: The Big Picture

Works with Your Existing Auth Stack

MCP Authentication

Getting Started

OpenID Connect Support

What's Next

Try It Today

The new Supabase power for Kiro

What are Kiro powers?

What you can do with the Supabase powers

Review edge functions

Check security and performance

Write better SQL

How it works

Get started

Built on open standards

Introducing Supabase ETL

Why separate OLTP and OLAP?

How it works

Setting up ETL

Available destinations

Analytics Buckets

BigQuery

Adding and removing tables

When to use ETL vs read replicas

Things to know

Pricing

Get started

Introducing Analytics Buckets

What do they do?

When to use Analytics Buckets vs Postgres

How they work

Creating an Analytics Bucket

Connecting to Analytics Buckets

Streaming data with Supabase ETL

Querying from Postgres

Data tiering pattern

Compatible tools

Pricing and availability

Get started

Introducing Vector Buckets

What are Vector Buckets?

What do Vector Buckets bring to the table?

Built-in similarity search

Performance that fits most app workflows

Metadata filtering

When should you use Vector Buckets vs pgvector?

Use pgvector when…

Use Vector Buckets when…

How do Vector Buckets work?

Designed for workloads up to tens of millions of vectors

Example scenarios

Availability

Get started

Top 10 Launches of Launch Week 15

#1: New API Keys + JWT Signing Keys

#2: Analytics Buckets with Apache Iceberg Support

#3: OpenTelemetry Support

#4: Build with Figma Make and Supabase

#5: Storage: 500 GB Uploads and Cheaper Cached Egress

#6: Edge Functions: Deno 2, 97% Faster Boot Times, and Persistent File Storage

#7: Branching 2.0: GitHub Optional

#8: Supabase UI: Platform Kit

#9: Stripe-To-Postgres Sync Engine as an NPM Package

#10: Algolia Connector for Supabase

Launch Week Continues

When should you use Vector Buckets vs `pgvector`?