Skip to content

Not an archive. A reasoning layer.

Memory that thinks.

Memory for AI agents that does more than store. Claude, ChatGPT, Cursor, and Codex write to one private memory — it reflects on what they learn overnight, and surfaces what nobody wrote down.

Hand this to your agent
Install my memory: https://oceandb.ai/docs/connect

ChatGPT and Claude Desktop connect from Settings → Connectors — about a minute. How to connect

Cursor · Tuesday 14:02 remember
{ title:   "Picked Supavisor pooler",
  content: "Port 6543, prepare: false.",
  type:    "decision",
  tags:    ["supabase", "pooler"] }

3:04 AM — the Dreamer 2 entries → 1 page · 1 insight

Claude · Friday 09:15 recall

"how do we connect to the database?"

page · supavisor

Supavisor transaction pooler, port 6543, prepare: false. 1

insight · from last night's run

Every connection bug this month traces back to prepare: true — worth a lint rule.

Saved once. Understood overnight. Known everywhere.

In plain terms

What is OceanDB?

OceanDB is a sovereign, self-managing memory layer for AI agents — memory that thinks, not an archive that waits. Claude, ChatGPT, Cursor, Codex, and any MCP client write to and recall from the same private store. Each night the Dreamer reorganizes what came in, turns the raw log into a readable, cited wiki, and writes down what it discovered along the way — while the underlying Postgres memory stays portable and under your control.

How the memory works

It remembers.

Every agent you use writes to one private log. One call captures the note, tags it, and embeds it for recall — so you can ask in different words, weeks later, from a different agent, and it still remembers. You never file, sort, or groom a note.

New conversation · ChatGPT

Set up the DB connection for the new service.

Using the Supavisor pooler on port 6543 with prepare: falseyou decided that in May after the IPv6 issue.

from memory · decision · May 12

entry · written by Cursor · May 12

"Port 6543, prepare:false for serverless. Direct host is IPv6-only — unreachable."

This chat was 30 seconds old.

It reflects.

Each night the Dreamer rereads what came in and thinks it over: it sorts the raw log into wiki pages, cites every fact back to the entry it came from, links what belongs together, and flags claims that can't both be true. It goes to bed a log. It wakes up a wiki.

The Dreamer ran 03:12 · 4m 08s
  1. Consolidate
    read 14 new entries · updated supavisor and 2 more pages
  2. Cross-link
    linked 3 entries into the wiki · 12 citations written
  3. Contradictions
    flagged 1 — held for your review
  4. Merge
    merged 2 duplicate pages you approved yesterday
entries processed: 14
pages: created 1 · updated 3
links: derived_from 12 · relates 3 · part_of 1
insights written: 1

It discovers.

Some of what a memory knows, nobody wrote down. As it works, OceanDB records what it noticed — the pattern across weeks of entries, the connection between two projects you never mentioned together. Findings, not search results: they arrive without your asking, and only to you.

Insight pattern
Sleep debt precedes trading losses

On 4 of the last 5 weeks, a poor-sleep entry lands 1–2 days before a red trading day. Neither journal mentions the other — the pattern only shows up across them.

from sleep trading-journal this morning

It compounds.

Every entry sharpens the next answer. Facts keep their citations, pages keep their history, and the memory deepens the longer your agents know you — a reasoning layer that gets better between the times you use it.

entity · tool /pages/supavisor kept by the Dreamer
Supavisor

The connection pooler in front of Postgres. App traffic runs through the transaction pooler on port 6543 with prepare: false1 — required because serverless connections are short-lived. Migrations use the session pooler on 5432 instead2. The direct database host was ruled out: IPv6-only, unreachable from the deploy target3.

Sources · 3 entries
  1. 1 "Port 6543, prepare:false for serverless." — Picked Supavisor pooler
  2. 2 "migrations use DIRECT_URL, the session pooler." — Migration setup notes
  3. 3 "db.<ref> host is IPv6-only — unreachable." — Deploy debugging session
connected part_of → Infrastructure relates ⇄ Drizzle setup

Thinks for whom?

And it's yours.

A memory that thinks raises one question: thinks for whom? All of it happens on your behalf. The reasoning runs through your own agent and your own model — the hosted server never runs one — over a plain Postgres database you can walk away with.

contradicts proposed by the Dreamer · last night
pricing-strategy

"Launch is usage-based — per memory written."

investor-update-june

"Committed to three flat tiers at launch."

These can't both hold. Which is current?

Resolve Dismiss nothing changes until you decide

No server-side model

The Dreamer runs client-side, from your own authorized agent, following a public playbook you can read.

Meet the Dreamer

Leaves whole

Private Postgres under row-level security. Export everything — content, relationships, provenance — as Markdown or SQL, any time.

Sovereignty and your data

For builders

Three tools. SQL underneath.

Your agent remembers and recalls; execute_sql is the full language when it needs more.

remember capture
remember({
  title: "Picked Supavisor pooler",
  content: "Port 6543, prepare:false
            for serverless.",
  entry_type: "decision",
  tags: ["supabase", "pooler"]
})

One call: inserts, tags, embeds — and returns the SQL it ran.

recall retrieve
recall({
  query: "which pooler, and why?",
  top_k: 5
})

→ pages first, then entries —
  semantic + full-text, fused

Hybrid search over the log and the wiki, with provenance.

execute_sql the language
select register, kind, title
from search_rings(
  'supavisor or pooler'
);

One statement, real Postgres — graph, tags, analytics, dreams.

Every tool runs de-fanged — SELECT, INSERT, UPDATE only; no DELETE, no DDL. A fresh connection is walked from empty to dreaming by onboarding_status. Run the Dreamer

Read

The field guide to memory that lasts.

The short answers

Before you connect it.

Does OceanDB work with Claude, ChatGPT, Cursor, and Codex?

Yes. Each connects to the same remote MCP endpoint and authorizes through the browser. They read and write one identity-scoped memory, so what one agent learns, every agent knows.

Connect an agent

Where does OceanDB memory live?

In a private Postgres database, separated into personal and shared workspaces by row-level security. Everything readable — content, relationships, provenance — can leave as Markdown or SQL. Embeddings are an index, not the only copy.

Sovereignty and your data

Does OceanDB run an AI model over your memory?

Not on the hosted server. The reasoning is the Dreamer, and it runs client-side — from your own authorized agent and chosen model, following a public playbook. It consolidates raw entries, links and cites as it goes, and sends uncertain contradictions or merges to you for review.

Meet the Dreamer

Is OceanDB only a vector database?

No. Vectors are one index among several. OceanDB combines Postgres rows, full-text search, semantic embeddings, and a typed link graph — so agents search by meaning, query by fact, and follow relationships. Simple remember and recall tools sit on top; restricted SQL is the full language underneath.

Inspect the schema

How is OceanDB different from RAG?

RAG retrieves at question time and forgets the rest. OceanDB reasons between questions: the Dreamer consolidates the raw log into cited pages, links related knowledge, and records what it discovers — so retrieval draws on memory that has already been thought through.

How the memory works

Give your agents a memory that thinks.

Connect it in a minute. Tonight it starts thinking — and every entry sharpens the next answer, the longer it knows you.

Install my memory: https://oceandb.ai/docs/connect

It remembers. It reflects. It discovers.