βAurabase Cloud est en bêta ouverte — accès instantanéObtenir un accès →
ACCUEIL/PRODUITS/REALTIME
REALTIME · SYNC NATIF

Sync, presence,
broadcast.

WebSocket, SSE et NATS auto-négociés. Presence, replay, ordering garanti, backpressure explicite. 1M connexions par POP, fanout sub-15ms p99.

14ms
P99 FANOUT
1M
CNX/POP
3
TRANSPORTS
Créer un canal Documentation
app/dashboard/live.tsxTYPESCRIPT
const channel = aura.channel('sensors:live')
channel
  .on('postgres_changes', {
    event: 'INSERT',
    schema: 'public',
    table: 'sensors',
    filter: 'tenant_id=eq.${tid}',
  }, ({ new: row }) => render(row))
  .subscribe()
// Auto-négocie WebSocket → SSE → NATS selon le réseau
#
Feature set

De la synchronisation primitive au jeu en temps réel

§ 01

3 transports auto-négociés

WebSocket d'abord, puis SSE, puis NATS côté serveur. Le client choisit le meilleur selon le réseau, sans intervention.

WS · SSE · NATS

Presence API

Qui est dans la room, état personnalisé, join/leave events. Consistent hash pour la réconciliation cross-region.

< 20ms SYNC

Multiplex N canaux

Ouvrez 1 000 canaux sur une seule connexion. Abonnement/désabonnement atomique, zéro coût réseau additionnel.

N CHANNELS · 1 TCP

Backpressure & ordering

Ordering garanti par canal, buffer côté client configurable, drop policy explicite. Pas de duplications silencieuses.

EXACTLY-ONCE PER-KEY

Event replay

Rejoue les N derniers événements à la reconnection. Configuré par canal, rétention par défaut 100 messages ou 60 secondes.

REPLAY WINDOW · 60s

Cursors collab

Primitive cursor native pour apps collaboratives. Throttle adaptatif côté serveur, interpolation côté client.

60 FPS · THROTTLED
#
Live feed

Ce que votre cluster reçoit, en vrai

§ 02

Aperçu d'un flux de production anonymisé. Chaque ligne est un événement dédupliqué et ordonné par canal, fanout sub-15ms vers tous les abonnés.

STREAM · eu-west-3 · channel_id = LIVE_SAMPLE
LIVEFANOUT · 9msCLIENTS · 12 418
14:32:08.412INSERTsensors:live·{ device_id: "dvc_9f2a", temp: 24.7 }
14:32:08.510PRESENCEdoc:42·user_j8k joined · cursor@(340, 120)
14:32:09.001UPDATEorders:live·{ id: "ord_77c", status: "shipped" }
14:32:09.188BROADCASTchat:general·{ event: "typing", user: "ci_42" }
14:32:09.440INSERTsensors:live·{ device_id: "dvc_4a1", temp: 23.9 }
14:32:09.702PRESENCEdoc:42·user_n3e left
14:32:10.020DELETEsessions:live·{ session_id: "sess_0x4" }
14:32:10.155BROADCASTgame:room-8·{ event: "move", coords: [12, 44] }
#
Performance

Chiffres publiés, pas marketing

§ 03
14ms
P99 FANOUT
Median 6ms — 1M clients simultanés, 12 régions actives
1M
CONNEXIONS / POP
Par point de présence, édition standard
256KB
MSG MAX
Par message — chunking auto au-delà
99.982%
UPTIME 30J
Incidents publics documentés sur /status
#
Comparaison

Aurabase · Supabase · Ably

§ 04
CapacitéAurabaseSupabaseAbly
TransportsWS · SSE · NATSWS seulWS · Binary
Presence nativeInclusInclusInclus
CDC PostgresInclusInclusNon
Event replayConfigurableNonOui (Ably)
MultiplexIllimité100 channels200 channels
FacturationConnexion × minConnexion × hMessage × event
Open sourceApache 2.0MITPropriétaire
#
Use case

1M événements/sec · 12 k clients

§ 05
MERIDIAN AI · RAG OBSERVABILITY · PARIS/SF

« On diffuse 1M événements/seconde à 12 000 clients simultanés. Latence p99 sous 15ms entre Paris et San Francisco. On a remplacé Pusher et notre stack Redis+Socket.io par un seul SDK. »

Leïla Mansour
Head of Platform · Meridian AI
#
FAQ

Questions fréquentes

§ 06
Quelle est la différence entre WebSocket, SSE et NATS ?+
WebSocket est bidirectionnel et notre défaut. SSE est unidirectionnel serveur-vers-client (utile derrière certains proxies corporate). NATS est le transport inter-services à l'intérieur de notre infra — si vous êtes sur un VPC Aurabase, vous pouvez brancher votre worker directement en NATS pour de la latence inter-process sub-milliseconde.
Les messages sont-ils garantis exactly-once ?+
Exactly-once par clé à l'intérieur d'un canal (ordering + déduplication via message_id côté serveur). Cross-canal, c'est at-least-once — le SDK expose seen_ids pour dédupliquer côté client si vous en avez besoin.
Comment scale-t-on au-delà de 1M connexions ?+
Ajoutez des POPs. Chaque POP accepte 1M connexions. L'état de présence est partitionné par hash consistant et répliqué en 3 copies. Nous avons un client de référence qui a soutenu 12M connexions simultanées sur 14 POPs.
Peut-on filtrer les CDC Postgres côté serveur ?+
Oui. filter: 'tenant_id=eq.$1' est évalué côté serveur via le WAL, et les clients n'ont accès qu'aux changes qui les concernent. Les policies RLS s'appliquent aussi aux événements realtime.
Et le mode hors ligne ?+
Le SDK maintient un buffer local (IndexedDB/AsyncStorage) et rejoue les intents au retour du réseau. Les conflits sont résolus via vector clocks optionnels ou par last-write-wins configurable par canal.
Quel est le coût réel ?+
Plan Free : 100 connexions simultanées × 1h/jour. Plan Pro : 100k connexions × heures de connexion totales dans le mois, à 0,015 € par 1k-heure de connexion. Pas de facturation par message dans l'édition Pro.
REALTIME ACTIVÉ PAR DÉFAUT

Ouvrez un canal, écoutez la production.

Aucune configuration. Un canal, trois lignes, un dashboard qui respire.

Aucune carte bancaire requise · 500 MB gratuits · 50 000 MAU