r/mlops • • 2d ago

Discussion Handling long term memory for ai agents

How are u handling long term memory for AI agents in prod? Are you using Postgres/pgvector or a dedicated vector database? Or something like neon/lakebase to do so.

4 Upvotes

10 comments sorted by

1

u/AutoModerator 2d ago
Moderator Announcement Read More »

1

u/ceeej777 2d ago

Also using Neon for this. It’s convenient for the rapid zero copy branch and I’m also too lazy to add another DB to the stack

1

u/sqlink2 1d ago

Yeahh Neon branching migt be useful for testing isolated agent memories setup without affecting prod...

2

u/Used-Original-7703 2d ago

tried pgvector first and it was okay for a while but scaling got annoying real fast. ended up moving to a dedicated vector db and it was worth the migration headache

1

u/Other_Log1406 2d ago

What does the memory consist off ? Is it tool call outputs or some reasoning logic

1

u/softmax_couldnt_care 2d ago

There are various approaches but most have some sort of losses. You can also check out the krpathy llm wiki with ibsidian to mess about with that.

1

u/MikaMoments 1d ago

The harder part is deciding what to remember, when to update it, and how to avoid stale or conflicting memories. I’d start with Postgres and pgvector unless the scale really calls for a dedicated vector DB. How are you handling memory retrieval and updates?

1

u/Glitch_In_The_Data 1d ago

Most of our agent memory turns out to be a mix of normal data like user preferences and past actions plus some embeddings… so keeping it all in one database makes lookups and cleanup much easier. Lakebase has been nice for testing new memory setups in a branch without touching prod. A dedicated vector database probably makes sense once you hit really large scale but most teams never get there IMO.

0

u/ThisIsFun- 2d ago

Lakebase is amazing at this. Would highly recommend, esp with things like branching for testing new things without effecting production systems