Use cases

One read layer,
many problems solved

ReflexDB fits wherever you need fast, reliable reads without adding load to your production database.

API caching

Serve read-heavy endpoints without touching production

Every read that hits your production database is a read that competes with writes, migrations, and analytics queries. ReflexDB removes that contention entirely by serving requests from an in-memory snapshot that stays current in real time.

In-memory row store — no disk I/O on query paths
Single-digit millisecond response times for simple lookups
No cache warming required — data is always synced
No stale-cache bugs — CDC propagates changes in under a second
Handles spikes without connection-pool exhaustion on primary

A product listing endpoint hitting the primary on every request could see p99 drop from hundreds of milliseconds to single digits after moving reads to ReflexDB.

query + response

POST /query HTTP/1.1
X-API-Key: rxk_live_…
Content-Type: text/plain

products(status = "active" AND stock > 0) {
  id name price_cents
} ORDER BY name ASC LIMIT 50

─── response (8 ms) ─────────────────
{
  "data": [
    { "id": 1, "name": "Acme Widget", "price_cents": 2499 },
    { "id": 2, "name": "Pro Widget",  "price_cents": 4999 },
    …48 more rows
  ],
  "meta": {
    "pagination": { "count": 50, "total_matched": 2841, "has_more": true },
    "timing_ms": 8.1
  }
}

Search indexes

A filtered read layer purpose-built for search

Search workloads need a different shape of data than your production schema provides. ReflexDB lets you declare exactly which rows and columns to expose — without schema changes, ETL pipelines, or dedicated infrastructure.

Per-table where predicates filter rows at sync time
Column allow-lists strip sensitive fields before they leave the DB
Field aliasing maps internal column names to clean API names
LIKE and ILIKE operators for prefix and substring matching
Deploy a separate instance per search surface (e.g. products vs. users)

reflexdb.yaml — search config

tables:
  products:
    # Only index published, in-stock rows
    where: "status = 'active' AND stock > 0"
    # Expose only search-relevant fields
    fields: [id, name, description, category, price_cents]
    field_aliases:
      price_cents: price

# Query from your frontend
POST /query HTTP/1.1

products(name ILIKE "%widget%") {
  id name description category price
} LIMIT 10

Analytics dashboards

Run aggregations without touching production

Dashboard queries — counts, sums, averages — are expensive on a live transactional database. ReflexDB executes them against an in-memory snapshot, with no query planner, no index selection, and no lock contention.

COUNT, SUM, AVG with implicit GROUP BY on any field
Multi-field ORDER BY for pre-sorted results
Nested aggregations across FK-linked tables
Results served from RAM — consistent latency regardless of table size
No impact on your primary DB, even during peak write load

aggregation query

# Revenue by status — dashboard widget
POST /query HTTP/1.1

orders(created_at > "2026-05-01") {
  status SUM(total_cents) COUNT(id)
}

─── response (3 ms) ─────────────────
{
  "data": [
    { "status": "shipped",   "sum": 9431000, "count": 471 },
    { "status": "pending",   "sum": 1248000, "count": 62 },
    { "status": "cancelled", "sum": 320000,  "count": 16 }
  ],
  "meta": {
    "pagination": { "count": 3, "total_matched": 3, "has_more": false },
    "timing_ms": 2.8
  }
}

Mobile backends

Typed REST endpoints without writing middleware

Mobile apps need read endpoints that are fast, authenticated, and shaped for the client. With ReflexDB, you get all of that generated from your schema — no custom API layer, no ORM, no resolver boilerplate to maintain.

API-key authentication on every endpoint — safe to call from mobile
Embed related records in one request — no N+1 on the client
OpenAPI spec available for generating typed client SDKs
Pagination via LIMIT + OFFSET for infinite scroll
Deploy a mobile-specific instance with only the tables the app needs

mobile app → ReflexDB

# Fetch feed with embedded author
POST /query HTTP/1.1
X-API-Key: rxk_live_…
Content-Type: text/plain

posts(published = 1) {
  id title created_at
  author { id name }
} ORDER BY created_at DESC LIMIT 20

─── response (5 ms) ──────────────────
{
  "data": [
    {
      "id": 482, "title": "Hello World",
      "author": { "id": 7, "name": "Alice" }
    },
    …19 more rows
  ],
  "meta": {
    "pagination": { "count": 20, "total_matched": 1284, "has_more": true },
    "timing_ms": 4.7
  }
}

AI integrations

Your database as a live data source for AI agents

AI agents and LLM workflows need structured, real-time data to answer questions accurately. ReflexDB's built-in MCP server exposes your database as queryable tools — immediately available to any client that supports the Model Context Protocol.

MCP server auto-generated from your instance schema — no extra configuration
Query your live data from Claude, Cursor, and other MCP-compatible tools
CDC sync means AI agents always see the current state of your database
API-key authentication — safe to expose to team tools
Available on all plans at no additional cost

MCP + Claude

# claude_desktop_config.json
{
  "mcpServers": {
    "reflexdb": {
      "url": "https://db_01J….reflexdb.cloud/mcp",
      "headers": {
        "Authorization": "Bearer rxk_live_…"
      }
    }
  }
}

# Claude now has live tools for your data
User:  "Top 5 products by revenue this month?"

[tool: query]
  query: orders(created_at > "2026-05-01") {
    product_id SUM(total_cents)
  } LIMIT 5

─── result (3 ms) ──────────────────
Widget Pro    $94,310
Basic Widget  $61,200

Multi-tenant

Separate read layers for every team or application

Different teams and apps need access to different slices of your data. Deploy separate ReflexDB instances with tailored schema configs — each exposing only the tables, columns, and rows its consumers need.

One instance per app, team, or environment — each with its own schema config
Column allow-lists ensure each consumer only sees the fields they should
Row predicates filter to the relevant subset at sync time
Independent API keys per instance — revoke one without affecting others
Deploy in different regions to serve distributed teams where they work

per-team configs

# Marketing team — reflexdb.yaml
tables:
  products:
    fields: [id, name, slug, price_cents]
  categories:
    fields: [id, name]
# endpoint: mktg.reflexdb.cloud

# Finance team — reflexdb.yaml
tables:
  orders:
    fields: [id, status, total_cents]
    where: "status != 'draft'"
  invoices:
    fields: [id, order_id, amount_cents]
# endpoint: finance.reflexdb.cloud

Ready to offload your read traffic?

Start with one free nano instance. No credit card required.

Start free See all features

One read layer,many problems solved