I have two AI subscriptions on my credit card. Each one keeps a private notebook about who I am, what I am working on, and how I want answers formatted. Each one forgets the other’s notebook exists. That mismatch used to cost me about ten minutes a day of re-typing the same paragraph into a fresh chat window, until I stopped letting either vendor own my notes and moved them to a database I control.
The thing that changed my mind was not a feature gap. Both assistants have decent memory on their own. What changed my mind was realizing that the companies have no reason to make those memories portable, and every reason to keep them locked in. The cost of that misalignment lands on the user, in small, easy-to-ignore increments, every time you open a new chat and start from zero. There is a workaround, and it is smaller than the marketing copy makes it sound.
What “memory” actually means in each product
Every assistant on the market has a feature with a name like “memory.” The user-facing experience differs more than the marketing suggests. Claude exposes labeled folders you can open, read, and edit by hand. It feels like a tidy filing cabinet. Gemini tucks most of what it learns into your chat history, which makes auditing annoying because you have to scroll through old conversations to find anything. ChatGPT does its own thing, and the other vendors have their own variants. None of them read each other’s notes. That part is not an accident.
You can see the misalignment in about thirty seconds. Open one assistant and ask “what do you know about me?” It will hand you a list. Open the other and ask the same question. It will hand you a vague answer and a pointer to a chat you had three weeks ago. Neither is lying. They just made different bets about whether memory should be auditable, and neither bet included a way to share with the other.
The practical effect is that if you write with one assistant, research with another, and code with a third, you have become the only common thread. You are the integration layer. That is the boring truth the marketing copy does not put on the landing page.
The fix is not a product, it is a small database
I stopped trying to make either vendor’s memory do the right thing and built my own. The whole thing is a Postgres database (a popular open-source relational database that stores information in tables with rows and columns) on a server I already had. Six tables. One for my background. One for active projects. One for output preferences. One for override rules, the small list of “do not assume” flags that override common defaults. One for last-write timestamps. One for new facts I want to remember but have not categorized yet.
Both assistants connect through their own APIs (the documented ways two programs talk to each other over the internet). When a chat begins, the assistant pulls the relevant rows. When it learns something, it writes a new row. That is the design. The reality is messier, which I will get to.
The Saturday afternoon it took to build this was not heroic. The schema was maybe twenty lines of SQL. The wiring on the Claude side was a ten-minute configuration in their console. The wiring on the Gemini side was a Google AI Studio workflow, more involved the first time but stable after that. The hardest part was reading the Gemini documentation, which is not great.
What breaks after launch, in order of annoyance
After a month of daily use, the rough edges sorted themselves into a predictable list:
- Write-back is unreliable on one side. It reads rows fine, then quietly skips the update step. I added a one-line reminder at the top of certain prompts and that closes about ninety percent of the cases. The remaining ten percent I just live with.
- Memory operations have a soft ceiling per session. Once you hit the cap, the assistant stops looking things up and starts answering from general knowledge. For short chats you never notice. For long ones, you do.
- Schema drift bites when you change the database. The day I added a new column, both assistants invented plausible-sounding answers about fields that no longer existed. They only stopped when I pasted the new layout into a follow-up prompt.
- Privacy is the question nobody wants to think about. You are storing personal context in a database. Where that database lives, who can read it, and whether it shows up in someone else’s analytics pipeline are decisions you have to make for yourself.
- Maintenance is a real tax. Change a project and you have to update a row. Skip it for a month and the assistants will confidently cite facts about your old job to a new client, and you will not notice until someone asks a follow-up question.
The privacy point is the one most articles skip past. If you care about keeping your context yours, run the database on a machine you own. Self-hosting on a Raspberry Pi or a small VPS (a virtual private server, basically a small rented computer you control remotely) is more setup work, but it means your notes do not flow through someone else’s logging system. There is no free lunch here, just choices about which trade-off you can live with.
When this earns its keep, and when it does not
Single-assistant users should not bother. The vendor’s built-in memory is fine, and adding a database you maintain is just another side project. The shared layer only makes sense if you genuinely split work across two or more tools, which is more common than people realize. You draft emails in one, summarize research in another, code in a third, and the only thing connecting all three is the typing speed of one person.
Stable context is the other prerequisite. If your projects rotate every week, the database becomes a chore that grows faster than it pays back. The benefit shows up when you describe yourself once and every assistant answers like they have known you for months. If you only ask one-off questions, the setup overhead is not worth it.
Trade-offs
Most of the build time went into the Gemini wiring, not into the database itself. The privacy question is the one to think about hardest. A managed Postgres service means trusting that service’s security with a small database that describes your work. For most people that is fine. For people handling confidential client work, running the database on a machine you own removes a category of risk that no amount of configuration can fully address. The functional difference is zero. The legal difference can be significant.
The honest verdict: if you only use one assistant, skip this and use the built-in memory. If you use two and you are tired of pasting your own context into every chat, the shared database layer is a fair trade-off for two hours of setup and the privacy question you will have to answer for yourself.
Bottom line
Try one thing first. Pick the assistant you use most, identify a single fact you are sick of re-typing, and let that assistant’s native memory handle it. If it works well, you may not need anything else. If it does not, or if you keep a second tab open and find yourself writing the same paragraph twice, a small database both assistants can read is worth the two-hour Saturday. Keep the schema small, host it somewhere you trust, and assume the assistant subscriptions will continue to cost what they cost today. The goal is to spend less time setting up every conversation, not to start a new infrastructure project.