Get early access
LatestViam test run2 Oct

Ask your robot’s memory.

ElideDB is a memory and a database for robots. It keeps everything their cameras and sensors record on one timeline, and answers in under a second when the robot’s code asks what happened before.

Get early access
  • Searchable about a second after each clip
  • Answers in under a second
  • No labels, captions or training

The problem

Robots record hours of video every day. Almost none of it can answer a question.

The footage exists: every camera, every shift, every attempt. Finding the one time a grasp slipped still means scrubbing through timelines by hand.

And a robot can’t scrub at all. Everything it saw yesterday is out of reach at the moment it acts today.

How it works

Record once. Ask with the video itself.

  1. 01 · Record

    Every camera and sensor, on one timeline.

    Video, joint states and telemetry stream in side by side while the robot works, and are kept as they were recorded.

  2. 02 · Index

    Searchable about a second after each clip ends.

    Each clip is indexed as it lands. No captions, no labels, no training on your footage.

  3. 03 · Ask

    Ask with the video itself.

    Show it the moment you care about. The moments most like it come back with their timestamps, the robot’s state beside every frame, and how each attempt ended.

robot-arm · 2 Oct REC 15:55:00indexed · 16 of 16query · 3 matches
15:55:0015:55:1615:55:32wrist cam13asktable cam2arm joints

Recording: two cameras and the arm’s joints

e·lide /ɪˈlaɪd/ — to leave out

The best read is the read elided.

A query reads only what its answer needs and leaves everything else where it lies. On the live arm, one search by example read less than half the store and opened no video at all.

In the store
365.3 MB
Read
154.4 MB
Elided
57.7 %

One search by example on the live arm’s store, 2 Oct 2026.

Proof

Measured on a live robot arm.

Two cameras and the arm’s joint state, recorded through Viam on 2 October 2026. Every figure below was read off that store.

  • 1.4sfrom a clip ending to it being searchable, median over every clip.
  • 0.5–0.75sfor the memory to answer the arm, before each grasp.
  • 47msto search by example, on the server. Median of five runs.
  • 3,127clips recorded and indexed in one afternoon.

Where it sits

The memory, not the controller.

ElideDB never moves a robot. A planner, a learned policy or your own program asks, and ElideDB answers with what happened before: the video, the robot’s state, what was tried and how it ended. The robot still decides.

  1. Cameras and sensorseverything the robot sees and does
    record
  2. ElideDBthe memory and the database
    ask · answer
  3. Your planner or policya VLA, a planner, your own code
    decides and acts
  4. The robot
No wire runs from ElideDB to the motors.

What it answers

Three questions, one memory.

  • Debug

    When did this happen before?

    Show it the moment a grasp slipped and get back every other time something like it happened, across cameras and days, ranked.

  • Recall

    What worked last time?

    Before acting, a robot’s code asks its memory. Past attempts come back, each with how it ended.

  • Curate

    Give me exactly that window.

    Pull any span as frames and sensor readings on one clock, ready to review or train on, without reading the rest of the recording.

Updates

From the lab.

Short videos of ElideDB at work, newest first.

0:59

Viam test run

ElideDB ran beside a robot arm on Viam, recording both of its cameras. Before each grasp, the arm asked its memory what had worked; each new clip was searchable about a second after it ended, and every pick went back in, graded worked or failed.

  • Live arm
  • Viam
  • Two cameras
Open on YouTube ↗

Give your robots a memory.

Early access is open to robotics teams. Tell us what your robots record, and we will show you what their memory can answer.

Get early access