Supabase ETL et Vector Buckets : vers le data lake

TL;DR

• Supabase Launch Week December 2025 marque un virage : la plateforme passe de "Firebase alternative" à "data platform".
• Les ETL pipelines permettent d'ingérer des données externes directement dans Supabase, sans outil tiers.
• Analytics Buckets (Apache Iceberg) ouvrent la porte a l'analyse de données massives sur PostgreSQL.
• Vector Buckets stockent des embeddings IA natifs, en remplacement de solutions comme Pinecone ou Weaviate.
• Supabase for Platforms permet aux SaaS de proposer du BaaS en marque blanche.
• C'est impressionnant, mais attention au vendor lock-in.

Le contexte : une Launch Week qui change la donne

Chaque trimestre, Supabase sort une Launch Week. En général, c'est des améliorations incrémentales : un meilleur dashboard, une feature Edge Functions, un fix de performance. Celle de décembre 2025, c'est autre chose. En cinq jours, l'équipe a posé les fondations d'une plateforme data complète. Et ça mérite qu'on s'y arrête.

Parce que le signal est clair : Supabase ne veut plus être "le Firebase open source". Ils veulent etre le layer data universel pour les apps modernes. Et les annonces de cette semaine montrent qu'ils ont les moyens de leurs ambitions.

ETL Pipelines : l'ingestion de données sans sortir de Supabase

Le problème qu'on avait tous

Avant, si tu voulais importer des données dans Supabase depuis une source externe -- un fichier CSV, une API tierce, un bucket S3 -- tu devais monter un pipeline ETL à côté. Airbyte, Fivetran, un script cron en Python... des outils supplémentaires, de l'infra en plus, de la complexité.

Ce que Supabase propose maintenant

Les ETL Pipelines sont intégrés directement dans le dashboard. Tu configures une source (S3, API REST, fichier), une transformation (SQL ou JavaScript), et une destination (ta table Postgres). Le tout tourne sur l'infra Supabase, avec un scheduler intégré.

-- Exemple simplifie : pipeline qui importe des produits depuis un CSV S3
CREATE PIPELINE products_import
  SOURCE s3('s3://mon-bucket/products.csv')
  TRANSFORM (
    SELECT
      col1 AS name,
      col2::numeric AS price,
      col3 AS category
    WHERE col2::numeric > 0
  )
  INTO products
  SCHEDULE '0 */6 * * *';

C'est du SQL étendu, pas un DSL propriétaire. Ça veut dire que tu peux le versionner dans Git, le reviewer en PR, et le tester en local. C'est une approche qui respecte les habitudes des devs backend.

Mon avis

Pour des pipelines simples à modérément complexes, c'est excellent. Ça élimine le besoin d'un outil ETL dédié pour 80% des cas. Mais pour de l'ETL enterprise avec des centaines de sources, des transformations complexes, et du monitoring avancé, Airbyte ou Fivetran restent supérieurs. Supabase couvre le cas du dev solo ou de la petite équipe -- et c'est exactement leur cible.

Analytics Buckets : Apache Iceberg dans Supabase

Pourquoi c'est important

PostgreSQL est excellent pour les requêtes transactionnelles (OLTP). Mais pour de l'analytique -- agreger des millions de lignes, calculer des tendances sur 12 mois, générer des rapports -- il souffre. Les index B-tree ne sont pas faits pour ca. Tu finis par monter un data warehouse a côté : BigQuery, Snowflake, ClickHouse.

Ce que Supabase fait

Les Analytics Buckets utilisent Apache Iceberg comme format de stockage sous-jacent. Iceberg, c'est le format open source qui a conquis le data engineering : colonnar, partitionné, avec du time travel et du schema évolution.

Concrètement, tu peux maintenant avoir des tables "analytics" dans Supabase qui stockent les données en format Iceberg. Les requêtes analytiques sont drastiquement plus rapides. Et tu gardes l'interface SQL que tu connais.

-- Creer un bucket analytique
CREATE ANALYTICS BUCKET user_events
  PARTITION BY (date_trunc('month', created_at))
  AS SELECT * FROM events
  WHERE event_type IN ('page_view', 'click', 'purchase');

-- Requete analytique sur le bucket
SELECT
  date_trunc('week', created_at) AS week,
  count(*) AS total_events,
  count(DISTINCT user_id) AS unique_users
FROM user_events
WHERE created_at > now() - interval '3 months'
GROUP BY 1
ORDER BY 1;

La réalité

C'est une approche intelligente : séparer le stockage OLTP (Postgres classique) de l'OLAP (Iceberg) tout en gardant une interface unifiée. Le dev n'a pas besoin d'apprendre un nouvel outil. Mais les performances restent à prouver sur des volumes serieux. Iceberg est conçu pour des petaoctets de données -- est-ce que l'implementation Supabase tient la route sur 10 milliards de lignes ? A tester.

Vector Buckets : les embeddings IA natifs

C'est l'annonce qui m'a le plus interesse. Les embeddings sont au coeur des applications IA modernes : recherche sémantique, RAG, recommandations. Jusqu'ici, tu avais deux options dans Supabase : utiliser pgvector (l'extension PostgreSQL pour les vecteurs) ou externaliser vers une base vectorielle dédiée comme Pinecone ou Weaviate.

Le problème de pgvector

pgvector fonctionne, mais il a des limites. Les index HNSW consomment beaucoup de RAM. Au-dela d'un million de vecteurs, les performances se dégradent. Et le stockage est celui de Postgres -- pas optimise pour des colonnes de 1536 floats.

Ce que Vector Buckets change

Vector Buckets sont un stockage dédié pour les embeddings, séparé du stockage Postgres classique. Les vecteurs sont stockés dans un format optimisé (pas en heap Postgres), avec des index construits spécifiquement pour la recherche de similarité.

-- Creer un vector bucket
CREATE VECTOR BUCKET document_embeddings
  DIMENSION 1536
  METRIC cosine;

-- Inserer des embeddings
INSERT INTO document_embeddings (id, embedding, metadata)
VALUES (
  'doc-001',
  '[0.023, -0.041, 0.087, ...]'::vector(1536),
  '{"title": "Guide technique", "source": "docs"}'
);

-- Recherche semantique
SELECT id, metadata, 1 - (embedding <=> query_embedding) AS similarity
FROM document_embeddings
ORDER BY embedding <=> query_embedding
LIMIT 10;

L'API reste du SQL. Pas de SDK propriétaire, pas de client spécifique. Tu queries tes embeddings comme tu queries n'importe quelle table. Et c'est ça, la force de l'approche Supabase : tout est PostgreSQL, tout est SQL.

Ce que ça implique

Pour les projets IA de taille moyenne (moins de 10 millions de vecteurs), Vector Buckets éliminent le besoin d'une base vectorielle externe. Un service en moins a gérer, une facture en moins, une intégration en moins. Pour les projets à l'échelle enterprise -- des centaines de millions de vecteurs avec des contraintes de latence strictes -- Pinecone et les solutions dédiées gardent l'avantage. Mais pour la majorité des devs qui construisent des features RAG ou de recherche sémantique, c'est suffisant.

Supabase for Platforms : le BaaS en marque blanche

L'annonce la plus stratégique, même si elle fait moins de bruit. Supabase for Platforms permet aux SaaS de proposer des instances Supabase à leurs propres clients. Gestion multi-tenant, provisioning automatisé, billing intégré.

Ça veut dire que si tu construis un SaaS vertical -- disons un outil de gestion pour restaurants -- tu peux donner a chaque restaurant sa propre instance Supabase, avec sa propre base de données, son propre auth, son propre storage. Sans gérer l'infra toi-même.

C'est un move à la Stripe : au lieu de concurrencer les SaaS, deviens l'infrastructure sur laquelle ils se construisent. Malin.

Le vrai sujet : vendor lock-in

Tout ca, c'est impressionnant. Mais il faut poser la question qui fâche : est-ce que Supabase est en train de devenir un nouveau lock-in ?

La réponse officielle, c'est que tout est open source et basé sur PostgreSQL. En théorie, tu peux migrer. En pratique, les ETL Pipelines, les Analytics Buckets, et les Vector Buckets utilisent des extensions et des syntaxes spécifiques à Supabase. Si tu veux quitter la plateforme demain, tu gardes tes données PostgreSQL, mais tu perds toute la couche de services autour.

C'est le même compromis qu'avec n'importe quel PaaS : tu gagnes en productivité, tu perds en portabilité. Mon approche : utiliser les services Supabase pour ce qui touche à l'infra (auth, storage, realtime), mais garder la logique métier dans du code applicatif standard. Si je dois migrer un jour, les migrations SQL et le code Python/TypeScript restent utilisables.

Comparaison avec les alternatives

La position de Supabase devient unique : c'est la seule plateforme qui combine BaaS, ETL, analytique et vecteurs dans un package open source basé sur PostgreSQL. C'est ambitieux. Le risque, c'est de faire trop de choses moyennement plutôt que quelques choses excellemment.

Mon verdict

Supabase décembre 2025 marque un point d'inflexion. La plateforme n'est plus un simple BaaS -- c'est un data platform. Pour un dev solo où une petite équipe qui construit un SaaS avec des besoins data (analytique, IA, ETL), c'est potentiellement la stack la plus complète du marché.

Mais "potentiellement" est le mot clé. Ces features sont nouvelles. La stabilité en production, les performances à l'échelle, le support enterprise -- tout ça reste a prouver. Mon conseil : adopte les nouvelles features pour tes side projects et tes MVPs. Pour la prod critique, attends quelques mois et surveille les retours de la communauté.

Et surtout, garde en tete que la meilleure base de données, c'est celle que tu maitrises. Si tu connais PostgreSQL, Supabase est un choix naturel. Si tu es à l'aise avec Firebase, les nouvelles features de Supabase ne sont pas une raison suffisante pour migrer.

Ressources

• Supabase Launch Week December 2025 -- toutes les annonces
• Apache Iceberg Documentation -- le format sous-jacent des Analytics Buckets
• pgvector -- l'extension PostgreSQL pour les vecteurs, base des Vector Buckets
• Supabase Vector Guide -- documentation officielle sur les fonctionnalités IA
• Supabase for Platforms -- documentation de l'offre multi-tenant