Why We Chose a Relational Database for an AI Travel Platform

I've had this conversation at least a dozen times. Someone hears we're building an AI-native travel platform and assumes we're using some exotic database. Graph database for the trip relationships? Vector store for the AI embeddings? A NoSQL document store because "that's what modern apps use"?

Nope. a relational database. The relational database that's been around since 1996.

This isn't a default choice made out of laziness. We evaluated alternatives seriously. a relational database won because the core transaction in our business is a booking, and bookings involve real money, real airline seats, and real consequences when things go wrong. For that, you need ACID transactions. And nobody does ACID better than a mature relational database.

When you need ACID or you need a lawyer

Here's what happens during a booking:

1. We charge the traveler's credit card.
2. We create a booking record in our database.
3. We update the trip to include the new booking.
4. We update the traveler's booking history.

These four operations need to succeed or fail together. If the payment goes through but the booking record doesn't get created, the traveler is charged for a booking that doesn't exist in our system. If the booking record is created but the trip isn't updated, the traveler's trip view is wrong. If any step fails, all steps need to roll back.

This is exactly what ACID transactions provide. Atomicity: all four operations complete or none do. Consistency: the database moves from one valid state to another. Isolation: concurrent bookings don't interfere with each other. Durability: once committed, the booking survives server crashes.

NoSQL databases generally offer eventual consistency. For a social media feed, eventual consistency is fine. If someone's like count is wrong for a few seconds, nobody gets hurt. For a booking where a credit card has been charged, "eventually" isn't good enough. The data needs to be correct right now, or someone is going to have a bad day.

Relational modeling for travel data

Travel data is inherently relational. A trip has bookings. Bookings have travelers. Travelers have documents. Documents have verification states. Trips have conversation threads. Threads have messages. Messages have tool calls.

These aren't loose associations. They're strict relationships with integrity constraints. A booking cannot exist without a trip. A document cannot exist without a traveler. An agent session cannot exist without a chat thread.

a relational database lets us enforce these relationships at the database level with foreign keys and constraints. If application code tries to create an orphaned booking (a booking with a trip ID that doesn't exist), the database rejects it. This is a safety net below the application layer. Bugs in application code can't corrupt the data integrity.

Our schema has ten-plus models with well-defined relationships: User, TravelerProfile, Preference, ChatThread, ChatMessage, AgentSession, Trip, Booking, Document, NotificationPreference, NotificationLog, and several more. Each relationship is explicit, queryable, and enforced.

Query patterns for travel search

Our AI agent needs to answer questions like "What time is my flight?" and "Show me all my trips this year." These queries span multiple tables with joins, aggregations, and filtering.

a relational database handles these query patterns exceptionally well. A query like "get this user's upcoming trips with their bookings, sorted by departure date" is a straightforward SQL query with joins. The query planner optimizes it based on indexes and statistics. We don't need to precompute or denormalize data structures to support common access patterns.

The indexes that matter for us:

• User ID indexes on every table that references a user, because almost every query is scoped to a specific user.
• Trip date indexes for chronological sorting and "upcoming trips" queries.
• Booking status indexes for filtering active vs. completed vs. cancelled bookings.
• Composite indexes on commonly joined columns to avoid sequential scans.

We run regular query analysis in staging to identify slow queries and missing indexes. A query that takes 100 milliseconds in development with 100 rows might take 5 seconds in production with 100,000 rows if the right index isn't in place.

What we deliberately avoid

a relational database has a rich ecosystem of extensions. We use very few of them, and that's intentional.

We don't use the JSON column type as a primary data structure. Some teams use a relational database's JSON support to store semi-structured data, effectively using a relational database as a document store. We keep our schema relational. If data has structure, it gets its own columns and relationships. JSON columns exist in our schema for genuinely unstructured data like raw API responses from external providers, but they're not queryable in our application layer.

We don't use a relational database for full-text search. Our search requirements are better served by application-level filtering and the AI agent's natural language understanding. Adding full-text search to the database would complicate our schema and queries for marginal benefit.

We don't use a relational database for real-time notifications. That's what our job queue and cache layer handle. Trying to use database triggers and LISTEN/NOTIFY for real-time features adds complexity without improving the user experience.

When we reach for the cache layer instead

Not everything belongs in a relational database. We use an in-memory cache for data that is read far more often than it's written and where stale data has minimal impact.

Airport and airline reference data is the clearest example. We have thousands of airports and hundreds of airlines. This data changes infrequently (maybe a new airline starts operating a route, or an airport code gets updated) but is queried constantly. Every flight search needs airport names and codes. Hitting the database for this on every query is wasteful.

We load reference data into the cache on startup and refresh it periodically. Cache reads are sub-millisecond. Database reads for the same data are 2-5 milliseconds. At hundreds of queries per second, that difference matters.

Session tokens and rate limit counters live in the cache because they're high-frequency writes with short TTLs. Writing a rate limit counter to a relational database 100 times per minute per user would generate pointless write load.

AI conversation context gets cached within a session but not across sessions. During an active conversation, the agent's working memory is in the cache for fast access. When the conversation ends, the persistent data is in a relational database and the volatile context expires.

The pattern is simple: if the data is transactional or needs to survive a restart, it goes in a relational database. If it's volatile, frequently accessed, and tolerant of staleness, it goes in the cache.

The decision framework

If you're evaluating databases for a booking platform, here's how I'd think about it.

Start with the hardest transaction. For us, that's a booking: payment + reservation + trip update in a single atomic operation. If your hardest transaction requires ACID guarantees, you need a relational database. Period.

Look at your query patterns. If most queries are "get this entity and its related entities," a relational database with joins is natural. If most queries are "scan all documents matching a fuzzy criteria," a document store might be more appropriate.

Consider your data integrity requirements. If orphaned records are a minor inconvenience, application-level validation is probably sufficient. If orphaned records mean real money problems, you want database-level constraints.

Don't pick technology based on what's trendy. Pick it based on what your data requires. a relational database isn't exciting. It's reliable. For a platform that handles travel bookings with real money, reliable is exactly what we needed.

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.