Database Design for AI Agent Memory

The memory layer is what separates an AI travel agent from a chatbot. Without memory, every conversation starts from zero. The agent does not know your seat preference, your budget range, the hotel you loved in Barcelona, or the airport you hate transiting through. With memory, each conversation is a continuation of a relationship that gets better over time.

Designing the storage layer for AI agent memory is one of the most interesting database architecture challenges I have worked on. It requires a hybrid approach because the data itself is hybrid: some of it is structured (trip dates, booking IDs, preference key-value pairs) and some of it is semantic (impressions, vibes, natural language descriptions of what you like). No single database type handles both well.

The memory storage challenge

AI agents need two fundamentally different types of data retrieval:

Structured queries. "What is the user's upcoming trip?" "When does their passport expire?" "What is their loyalty program number?" These are precise, lookup-based queries with exact answers. They belong in a relational database with ACID guarantees.

Semantic queries. "What kind of hotels does this user like?" "What was the experience they had in Barcelona that they keep referencing?" "Find preferences similar to this new user's early behavior." These are similarity-based queries that require understanding meaning, not matching keywords. They belong in a vector database.

Trying to force semantic queries into a relational database produces bad results. You end up with preference tables that have columns like "hotel_style: boutique" and "neighborhood: walkable," which capture some preferences but miss the rich, unstructured context that makes personalization feel human.

Trying to force structured queries into a vector database produces unreliable results. Nearest-neighbor search on embeddings is great for "find similar preferences" but terrible for "what is the booking confirmation number for trip 4829."

The answer is both. A hybrid architecture where relational storage handles structured data and vector storage handles semantic data, with a query router that directs each query to the appropriate store.

Relational storage

Our relational database stores the transactional core of the travel agent:

User table. Name, email, authentication details, account creation date. Standard user management.

Trip table. Trip ID, destination, dates, status (planned, booked, completed, cancelled). One user has many trips.

Booking table. Booking ID, trip ID, booking type (flight, hotel), provider reference, price, status, cancellation policy. One trip has many bookings.

Traveler profile table. Passport data, dietary restrictions, loyalty program numbers, emergency contacts. Structured, verified data that the agent uses for booking execution.

Preference table (structured). Key-value pairs for explicit, declared preferences. Seat preference: aisle. Default cabin: economy. Budget range: $800-1,200 for domestic flights. These are facts, not vibes.

Conversation table. Chat thread records with message history, role, content, and timestamps. The conversation log for reference and replay.

This schema looks like any standard web application database. The tables are normalized, the relationships are clear, and queries are fast and predictable. Nothing exotic here.

Vector storage

The vector database stores the semantic dimension of memory:

Preference embeddings. Natural language preference statements are embedded and stored. "I love small boutique hotels in residential neighborhoods with local character" becomes a 1536-dimensional vector that can be compared against hotel description embeddings.

Trip memories. Summaries of past trips are embedded. "The Barcelona trip was amazing. The hotel in the Gothic Quarter was perfect. Quiet at night, walking distance to everything, rooftop with city views." This memory is retrievable when the user says "something like Barcelona" even months later.

Behavioral patterns. Inferred preferences are embedded as composite vectors. The system observes that the user consistently books direct flights, prefers morning departures, and chooses hotels in walkable neighborhoods. These patterns are encoded as embeddings that inform future searches.

Vector storage enables the "it gets you" feeling. When the user says "I want something cozy," the agent finds memories and preferences semantically related to "cozy" (small hotels, fireplaces, local restaurants, quiet streets) and uses them to refine the search.

Hybrid architecture

The query router sits between the AI agent and both databases. When the agent needs information, the router determines where to look:

Structured lookups go to the relational database. "What are the user's upcoming trips?" "What is their passport number?" "Which credit card is on file?" Fast, exact, reliable.

Semantic retrieval goes to the vector database. "What kind of hotels does this user prefer?" "What was the experience they keep referencing?" "Find users with similar preferences for collaborative filtering." Fuzzy, similarity-based, nuanced.

Combined queries hit both. "What hotels should I recommend for this user's trip to Lisbon?" requires relational data (trip dates, budget) and semantic data (hotel preference patterns). The router runs both queries in parallel and merges the results into a single context block for the agent. The parallel retrieval pattern is important for latency. The agent needs this context within the conversation's latency budget. Running relational and vector queries sequentially doubles the retrieval time. Running them in parallel keeps it under 100ms total.

Query patterns for conversation

The agent retrieves memory context at the start of each turn. The retrieval needs to be:

Fast. Under 100ms. Memory retrieval cannot add perceptible latency to the conversation. This means indexed relational queries and optimized nearest-neighbor search with appropriate index structures.

Relevant. The retrieved context should be relevant to the current conversation topic. If the user is asking about flights to Tokyo, their hotel preferences in Barcelona are less relevant than their previous Tokyo searches. The vector query is scoped by current context to improve relevance.

Compact. The retrieved context feeds into the LLM's context window. A memory dump of everything known about the user would consume thousands of tokens. We retrieve only the most relevant items (top-5 semantic memories, active trip details, key preferences) to keep the context window manageable.

Scaling memory

As the user base grows, both databases need to scale:

Relational scaling is well-understood. Read replicas for query distribution, connection pooling, index optimization, and partitioning by user ID. Standard database engineering.

Vector scaling is newer but similar in principle. Approximate nearest-neighbor indexes (HNSW, IVF) trade a tiny accuracy loss for massive speed gains. Partitioning by user ID keeps per-user queries fast even as the total vector count grows into the millions.

The critical performance metric is retrieval latency at the 99th percentile. The median query might be fast, but a slow outlier delays one conversation in a hundred. We optimize for the tail, not just the average.

Data lifecycle

Memory is not permanent. Travel preferences change. Old trip memories become less relevant. And users have the legal right to request deletion of their data.

Archival. Trip memories older than two years are moved to cold storage. They are still retrievable if the user references them, but they are not included in the default context retrieval. This keeps the active memory set manageable.

Decay. Preference weights decrease over time. A hotel preference expressed three years ago is weighted less than one expressed last month. This prevents stale preferences from overriding recent behavior.

Deletion. GDPR and CCPA require that users can delete their data. A deletion request triggers a cascade: relational records are deleted, vector embeddings are removed, cached data is invalidated, and analytics entries are purged. The deletion must propagate across both storage systems completely.

We built the deletion pipeline early and test it regularly. Incomplete deletion is a compliance violation. The pipeline runs automated verification after each deletion to confirm that no traces remain in either database.

The memory layer is the competitive moat of an AI travel agent. The models are interchangeable. The travel data is the same for everyone. But the memory, what the agent knows about each user, is unique and compounds over time. Getting the database architecture right is getting the moat right.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.