I pay for both Claude and Gemini, and for months I opened each one the same way, with a paragraph explaining my background, what I’m working on, and how I want answers structured. Like a lot of people, I’ve ended up splitting work across different AI assistants, which means keeping two separate copies of my own context in my head. So I gave them a shared one instead. Both now read from and write to the same Postgres database. One of them uses it properly, and the other needs reminding.

This is not a free-tier project. Only Claude lets you do it for free, and the Gemini side needs a Google AI plan with Spark. The database costs nothing, but the assistants do.

Each assistant keeps its memory to itself

The re-explaining drains energy fast

Claude and Gemini both remember things about you, and both do it reasonably well on their own terms. Neither can see the other’s copy. Claude sorts what it learns into labeled categories you can open and edit, while Gemini keeps most of what it picks up inside your chat history rather than a readable list, a gap that becomes obvious the moment you test what each assistant actually stores about you.

Neither company has much reason to close that gap. Memory is part of what keeps you in one app rather than the other, so the incentive runs the wrong way.

The cost lands on you in small increments. Every new Gemini chat got the same three sentences about my engineering background, the tools I actually run, and how much detail I want back. Every new Claude chat got a version of the same thing. None of it was hard, and that was the problem. It was small enough to keep doing and annoying enough to notice.

One free Postgres database now feeds both

Neon hosts the whole thing for free

The fix is a database both assistants can reach. I used Neon, which hosts Postgres in the cloud and has a free tier that covers something this small without a credit card. Building the store takes about five minutes:

1. Sign up at Neon and create a project, giving it any name you like.
2. Open the SQL Editor and create one table with columns for a category, the fact itself, a source, and a timestamp.
3. Add a handful of starter rows so there’s something to read back on the first test.

The source column is the one worth explaining. Every row records which assistant wrote it, so when Claude saves something and Gemini reads it back, you can see exactly where it came from. Without that column, you’re taking the whole thing on faith.

The connection runs on the Model Context Protocol (MCP), an open standard that lets an assistant call outside tools. Most Postgres MCP servers are built to run on your own machine, and neither app can reach those, since both call out from their own servers rather than from your computer. Neon publishes a hosted endpoint instead, which is what makes this work.

By default, the connector can reach every project in your Neon account. If you keep anything else there, scope it to a single project ID before you connect either assistant.

Claude reaches for the memory unprompted

A standing instruction was all it needed

Claude takes about two minutes on the web, and the connector carries over to mobile afterward:

1. Open Settings, then Connectors, and click Add.
2. Paste Neon’s hosted endpoint https://mcp.neon.tech/mcp, then complete the sign-in when the authorization window opens.
3. Switch the connector on from the + menu inside a new chat.

The connection on its own doesn’t do much. An assistant with a tool available only uses it when it decides the moment calls for it, and left alone, Claude mostly didn’t. What changed was one line in the personal preferences field, telling Claude to check the table before answering and to write anything durable back to it. After that I stopped asking.

The test that convinced me was simple. I mentioned in passing that I’d moved all my project notes over to Obsidian, then opened the database and found a new row waiting, with the source set to Claude. I hadn’t asked it to save anything.

That’s the behavior the whole setup rests on. Plenty of people solve the same problem by leaning on a single assistant for everything, which works, but I’d rather keep both and have them share what they know.

Gemini Spark waits for an @ mention

Google’s own connectors get first pick

Gemini takes the same endpoint, with one prerequisite:

1. Turn on Keep Activity in Gemini’s settings, because Spark refuses custom connections without it.
2. Switch to Spark and click Connected Apps, then scroll to Custom apps for Spark.
3. Click Add a custom app and paste the same endpoint https://mcp.neon.tech/mcp, click through, and complete the sign-in.

When I asked it to list the rows, Spark returned every one of them, so the plumbing was never in question.

Then I opened a fresh conversation and asked what it knew about how I work. Spark answered from my Google Drive. It wasn’t wrong exactly, since it had found a document that covered some of it, but it never touched the memory table at all.

The reason isn’t mysterious. Gemini’s saved info shapes how it talks to you, but it doesn’t drive tool selection the way Claude’s preferences do. Google’s first-party connectors also sit closer to hand than anything third-party, and once Personal Intelligence is wired into your everyday apps, Drive and Gmail are always the shorter path to a plausible answer.

Typing @ and picking the app fixes it instantly. Every row comes back, and the answer is right. You just have to remember to do it every time.

Google has an easier answer to all of this, and it deserves credit. You can bring your chats and memory into Gemini directly from Claude, with no database involved, and for a one-time move it’s the better tool. What it copies is a snapshot, though, and a snapshot stops updating the moment it lands.

One @ still beats retyping a paragraph. I’d rather Gemini reached for the memory on its own, but the memory is shared either way, and that was the point.

Where I would take this setup next

The table doesn’t care how many things read from it

Two assistants is where this stops being an experiment and starts being infrastructure. A third is one subscription away. I’d also scope the connector to read-only for anything I wouldn’t want rewritten, which takes a single query parameter. The change I actually want sits on Google’s side, where a custom app should count as a real memory source rather than a fallback that Drive gets to outrank. Until then, I’ll keep typing @ and keep not explaining myself twice.