Search. Auth.
Realtime. Replicas.
One binary.

Reference SDK shape

The historical SDK sketch below preserves the API shape that informed KynetraDB’s design. Compatibility is scoped per preview; public parity is not claimed.

import { createClient } from '@kynetra/client'

const kdb = createClient('https://api.myapp.com', PUBLISHABLE_KEY)

// Query — fluent builder, fully typed
const { data, error } = await kdb
  .from('posts')
  .select('id, title, author(name)')
  .eq('published', true)
  .order('created_at', { ascending: false })
  .range(0, 19)

// Auth
const { data: { session } } = await kdb.auth.signInWithPassword({ email, password })
const { data: { user } }    = await kdb.auth.getUser()

// Storage
await kdb.storage.from('avatars').upload(`${user.id}.png`, file)
const { data: { publicUrl } } = kdb.storage.from('avatars').getPublicUrl(fileId)

// Realtime — change events + presence + broadcast
kdb.channel('live')
  .on('postgres_changes', { event: 'INSERT', table: 'messages' }, payload => {
    console.log('new message', payload.new)
  })
  .subscribe()

// Edge functions
await kdb.functions.invoke('send-welcome', { body: { userId: user.id } })

// Full-text + vector search
const { data: hits } = await kdb.from('docs').textSearch('body', 'rust async')
const nearest = await kdb.rpc('vector_search', { query: embedding, top_k: 10 })

Distribution is scoped during preview

const kdb = createClient(
  process.env.KYNETRA_URL,
  process.env.KYNETRA_KEY
)

Capability reference catalogue

Reference architecture — implementation scope is agreed per preview. One hundred capabilities are catalogued, each carrying the status a dated audit gave it after naming the source file, API surface and test result behind it.

• 51available
• 9beta
• 21roadmap
• 19research

The audit downgraded three of its own entries on review; those are published as found.Read the capability audit → ·Browse all 100 →

Reference architecture

Most backend stacks are a fleet of processes — a database, a search engine, a cache, an auth service, a storage API, a realtime broker. Each one is a separate deploy, a separate failure surface, and a separate ops burden.

The original KynetraDB architecture model collapses these concerns into a single data-plane boundary. The diagram is retained as a technical reference:

Your app (Next.js / React / Vue / mobile / CLI / MCP)
      │
      │  @kynetra/client  ·  REST  ·  MCP  ·  CLI
      ▼
kynetradb  ─── one process · one Dockerfile · one WAL
      ├── /rest/v1      query layer (select/filter/order/embed)
      ├── /auth/v1      email + OAuth + JWT + RLS
      ├── /storage/v1   buckets · signed URLs · S3-compatible
      ├── /realtime/v1  WebSocket channels · presence · broadcast
      ├── /functions/v1 WASM edge functions
      ├── BM25 full-text  p50 0.025 ms @ 100k ← built-in
      ├── vector search   HNSW + SPANN · p99 0.514 ms @ 1M ← built-in
      └── Read replicas   WAL fan-out · staleness p99 17 ms ← built-in

One reference model. One comparison catalogue. 19 target profiles.

Every figure on this site is local-scope: one host, one operator, no third-party reproduction. Artifacts are linked next to each number, and gates that were missed are published beside the gates that were met. See the full benchmark ledger →

Current reference state

This is a private-preview reference surface. Read the fullState sectionbefore betting anything serious on it.