Rylvo Conversation Storage (BYODB): Own Your AI Conversation Data with Webhook and Direct Database Sync

Every conversation your AI bot has with a customer is valuable data. It contains support issues that reveal product problems. It contains sales inquiries that show buying intent. It contains feedback that drives product roadmaps. It contains the complete transcript of your customer relationships. But who owns that data? Where does it live? How long is it retained? Can you analyze it alongside your CRM records, support tickets, and analytics warehouse?

Most AI bot platforms store every conversation in their own database. You get a dashboard, maybe an export button, but the data lives on someone else's servers. You pay for storage you do not control. You cannot run custom queries. You cannot set your own retention policy. You cannot join conversation data with your other systems. And if you ever leave the platform, getting your data out is an ordeal.

Rylvo Conversation Storage, also known as Bring Your Own Database (BYODB), changes this completely. It lets every organization connect its own database or webhook endpoint as the permanent home for bot conversations. Rylvo continues to keep a time-bounded operational copy in Firestore so observability features like Mission Control, traces, and Agent Evolution keep working — but your database is the source of truth. You choose the database. You choose the schema. You choose the retention.

In this guide, we will explore the complete Conversation Storage system: why it matters, the architecture, two connection modes, eight supported database drivers, four schema templates, five event types, the four-tab dashboard, security model, retention policies, and how to connect your first storage target in minutes.

Why Data Ownership Matters

Before Conversation Storage, Rylvo stored 100% of end-user conversations in Firestore. This created three problems that grew more severe as organizations scaled.

Cost. High-volume organizations generate millions of messages per month. Storing all of them in a managed database influtes the platform's footprint and passes costs to customers who have no alternative.

Ownership. Retention policy, deletion rights, and data residency are the customer's call, not the platform's. Some industries require conversations to be deleted after 30 days. Others require them to be retained for seven years. Some must stay in a specific geographic region. When the platform controls the storage, the customer has limited flexibility.

Integration. Customers wanted conversation data to live next to their CRM records, support tickets, analytics warehouse, and custom dashboards. Without a direct sync, they needed export pipelines, ETL jobs, and manual reconciliation — all of which add latency, cost, and failure modes.

The new model splits the responsibility cleanly. Your database is the permanent, authoritative store. Rylvo's Firestore copy is temporary and operational, automatically pruned after your plan's retention window. You get the best of both worlds: complete data ownership plus full platform observability.

Architecture: Dual-Write with Fire-and-Forget Delivery

When a user sends a message and the bot replies, the conversation storage system follows a precise dual-write flow.

First, the message is written to Rylvo Firestore as an operational copy. This is synchronous and immediate, ensuring the chat interface, Mission Control, and trace system all see the message without delay.

Second, a fire-and-forget POST is sent to the backend worker at /v1/conversation-storage/push. This call is deliberately non-blocking. The chat flow continues regardless of whether the storage sync succeeds or fails. The request uses keepalive: true so it completes even if the browser tab unloads.

Third, the backend resolves the organization's storage target configuration. If the target is in webhook mode, it POSTs a JSON payload to the customer's URL with authentication headers. If the target is in direct database mode, it decrypts the connection string and writes directly to the customer's database.

Fourth, the outcome is recorded. The target document counters are updated with total events pushed and total errors. An audit log entry is appended to the conversation storage logs for troubleshooting and compliance.

Rylvo's own Firestore copy is auto-pruned after the organization's trace retention window. Your database copy never expires unless you configure it to.

Two Connection Modes: Webhook and Direct Database

Conversation Storage supports two connection modes, giving organizations flexibility in how they receive conversation data.

Webhook Mode

The simplest option. You host an HTTPS endpoint, and Rylvo POSTs a JSON payload to it on every event. This is ideal when you already have an API that accepts external data, when you want to process conversations through an existing pipeline, or when you prefer not to expose database credentials.

Supported authentication methods for webhook mode include none for public endpoints, API key sent as a custom header, Bearer token via the Authorization header, and HMAC-SHA256 request signing with a shared secret.

The payload includes the event type, organization ID, bot ID, conversation ID, the full message payload with role, content, metadata like model and latency, and a timestamp. Rylvo expects a 2xx response for success. Anything else triggers exponential backoff retries.

Direct Database Mode

For organizations that want data written directly into their existing database without building a webhook receiver. Rylvo connects to your database using a connection string you provide. Credentials are encrypted at rest with a server-held Fernet key and are never returned from any read API. This is ideal when you want conversation data in the same database as your other application data, when you need the lowest possible sync latency, or when you prefer SQL inserts over HTTP webhooks.

Eight Supported Database Drivers

Direct database mode supports eight popular database systems with native drivers.

PostgreSQL is supported with standard connection strings, making it compatible with self-hosted Postgres, Amazon RDS, Google Cloud SQL, and Azure Database. Supabase uses the same PostgreSQL connection string format, with the pooler URL recommended for serverless workloads. Neon also uses PostgreSQL connection strings and works seamlessly with Neon's serverless Postgres offering.

MySQL is supported with standard connection strings for self-hosted MySQL, Amazon RDS, and Google Cloud SQL. PlanetScale uses MySQL-compatible connection strings with SSL configuration for Vitess-based serverless databases.

Turso is supported via LibSQL connection strings with auth tokens, ideal for edge-distributed SQLite workloads. MongoDB is supported with both standard and SRV connection strings for MongoDB Atlas and self-hosted clusters.

Redis is supported for organizations that want to stream conversation events into a real-time data structure store for caching, pub/sub, or time-series analysis.

Four Schema Templates: From Normalized to Minimal

Rylvo ships four ready-to-use schema templates. You can use any template as-is, fork it into a custom schema, or build your own from scratch.

Default Relational

Best for PostgreSQL, MySQL, Neon, PlanetScale, Turso, and Supabase. This template creates three normalized tables: one for conversations, one for messages, and one for sessions. It follows classic relational design with foreign keys, indexes, and proper normalization. Ideal when you want to run complex SQL queries, joins, and aggregations across your conversation data.

Flat Messages

Best for analytics warehouses and data lakes. This template uses a single denormalized table with one row per message. Bot ID, conversation ID, and session ID are inline columns rather than separate tables. Ideal when you want to load data into BigQuery, Snowflake, Redshift, or ClickHouse for analytics and reporting.

MongoDB Document

Best for MongoDB and other document stores. This template creates one document per conversation with an embedded messages array. It matches MongoDB's document-oriented design and is ideal when you want to store conversations as self-contained documents that can be queried as a unit.

Minimal

Best for transcript-only use cases. This template stores only the essential fields: message ID, conversation ID, role, content, and created timestamp. It is the smallest footprint option and ideal when you just need a text transcript without metadata, metrics, or relational structure.

Every template exposes a fields map that translates Rylvo canonical keys into your column or field names. Set any field to an empty string to skip writing it. You can also append custom fields that Rylvo will populate from event metadata.

Custom Schemas

Two customization paths are available. The plug-and-play path uses the Schema Designer tab in the dashboard to change column names field by field with a live preview. The code mode path lets you edit the ConversationSchemaDefinition JSON directly, validated on save. For relational drivers, the Schema Designer shows the CREATE TABLE SQL for your selected template, and clicking Run Migration executes the DDL against your database using CREATE TABLE IF NOT EXISTS — safe to re-run.

Five Event Types: Comprehensive Conversation Coverage

Conversation Storage emits five event types, giving you granular control over what gets synced.

Conversation Created fires when a new chat conversation is opened. This lets your system create a conversation record before any messages arrive. Message Appended fires on every user message, assistant response, system message, or operator-authored message. This is the most common event and carries full message content plus metadata like model, latency, token count, and trace ID. Conversation Ended fires when a conversation is marked as ended. Conversation Archived fires when a human operator archives a conversation. Session Summary is planned for future periodic rollups of long-running chat sessions.

Per target, you choose which events to sync. By default, all events except session summary are synced. This lets you, for example, only sync message appends if you do not need conversation lifecycle events.

The Four-Tab Dashboard: Complete Storage Management

The Conversation Storage dashboard at /dashboard/conversation-storage provides four tabs for managing every aspect of your data sync.

Connections Tab: Storage Targets at a Glance

The Connections tab lists all your storage targets with real-time status, target counts, and per-target details. Each target card shows its name, mode (webhook or direct database), driver, status, linked bots, event count, error count, and a health indicator. You can create new targets, edit existing ones, test connections, and monitor sync health.

Schema Designer Tab: Visual Schema Customization

The Schema Designer tab lets you customize your data schema without writing SQL. Select a built-in template, change column names, preview the resulting schema, and run the DDL migration against your database. Live preview shows exactly what tables or collections will be created. One-click DDL execution handles CREATE TABLE IF NOT EXISTS safely.

Sync Logs Tab: Audit Trail and Troubleshooting

The Sync Logs tab provides a per-event audit trail showing every push attempt, its success or failure status, latency, retry count, and error message. This is essential for debugging connection issues, verifying data delivery, and proving compliance. Logs are searchable and filterable by target, event type, and status.

Retention Tab: Plan-Aware Data Lifecycle

The Retention tab shows your current plan's retention policy and how long Rylvo keeps the operational copy. It explains the difference between your permanent database copy and Rylvo's temporary copy, helping you understand where data lives and for how long.

Security: Encrypted, Signed, and Never Exposed

Security is foundational to Conversation Storage. Credentials are encrypted with a server-held Fernet key and are never returned from any read API. The only places plaintext touches Rylvo are: the Create wizard's test step, which sends plaintext to the test endpoint without persisting it; the one-time encrypt call on save, which converts plaintext to ciphertext; and the backend push worker, which decrypts ciphertext to dispatch data, never logging the plaintext.

No credentials appear in Firestore reads. The webhook auth value and connection string fields are ciphertext only. For webhook mode, HMAC-SHA256 signing lets you verify that every payload came from Rylvo. Rate limits inherit from your plan tier, and the backend enforces webhook timeout and retry count per target.

Retention: Plan-Tiered Operational Copies

Rylvo's own operational copy in Firestore is automatically deleted after your plan's retention window.

Free plans get 7 days of operational retention. Starter plans get 30 days. Growth plans get 90 days. Scale plans get 180 days. Enterprise plans get unlimited or negotiated retention. Longer retention reserves more of Rylvo's database footprint for your organization and is priced into the tier. Your own database copy keeps data forever unless you configure your own expiry.

Plan Limits

Conversation Storage is available on Starter and above. Free plans cannot create storage targets. Starter plans get 1 target. Growth plans get 3 targets. Scale plans get 10 targets. Enterprise plans get unlimited targets.

Comparison: Rylvo BYODB vs. Platform-Owned Storage

Getting Started

Step 1: Upgrade Your Plan

Conversation Storage requires at least a Starter plan. Navigate to /dashboard/billing and upgrade if needed.

Step 2: Open the Conversation Storage Dashboard

Navigate to /dashboard/conversation-storage. The Connections tab shows any existing storage targets.

Step 3: Create Your First Storage Target

Click New Storage Target. Choose between webhook mode or direct database mode. For direct database mode, select your driver, enter the connection string, and test the connection. For webhook mode, enter your endpoint URL and choose an authentication method. Select which bots should sync to this target and which events to sync.

Step 4: Design Your Schema

Go to the Schema Designer tab. Pick a template that matches your database type. Customize column names if needed. Preview the schema. Click Run Migration to create the tables in your database.

Step 5: Verify Sync

Start a conversation with one of your linked bots. Go to the Sync Logs tab and verify that message append events are being delivered successfully. Check your database to confirm the data arrived.

Step 6: Monitor and Adjust

Review the Sync Logs regularly for errors. Adjust the schema in the Schema Designer if needed. Add or remove linked bots as your deployment grows.

FAQ

What is Rylvo Conversation Storage? A Bring Your Own Database (BYODB) feature that lets you connect your own database or webhook endpoint as the permanent home for bot conversation data, while Rylvo maintains an operational copy for platform observability.

What connection modes are supported? Webhook mode (HTTP POST to your endpoint) and Direct Database mode (Rylvo writes directly to your database).

Which databases are supported? PostgreSQL, Supabase, Neon, MySQL, PlanetScale, Turso (LibSQL), MongoDB, and Redis.

What schema templates are available? Four: Default Relational (3 normalized tables), Flat Messages (single denormalized table), MongoDB Document (one document per conversation), and Minimal (transcript-only).

Can I customize the schema? Yes. Use the Schema Designer for visual customization or edit the JSON schema definition directly. You can rename fields, skip fields, and add custom fields.

What events are synced? Conversation Created, Message Appended, Conversation Ended, Conversation Archived, and Session Summary (future).

Does this slow down chat? No. Storage sync is fire-and-forget and non-blocking. The chat flow continues regardless of sync success or failure.

How are credentials secured? Encrypted at rest with a server-held Fernet key. Never returned from any read API. Only decrypted by the backend push worker.

Can I scope storage targets to specific bots? Yes. Each target can be linked to all bots or specific bots.

What happens if a sync fails? Webhook mode retries with exponential backoff. Direct database mode retries via the backend worker. Failures are logged in the Sync Logs tab with error details.

How long does Rylvo keep the operational copy? 7 days on Free, 30 days on Starter, 90 days on Growth, 180 days on Scale, unlimited on Enterprise.

Ready to Own Your Conversation Data?

Rylvo Conversation Storage gives you something no other AI bot platform offers: true ownership of your customer conversation data. Your database is the source of truth. Your schema reflects your needs. Your retention policy matches your compliance requirements. Your queries join with your CRM, support tickets, and analytics warehouse. And Rylvo's operational copy ensures you still get the full power of Mission Control, traces, and Agent Evolution.

You are not renting storage from a platform. You are extending your own data infrastructure with a first-class sync layer.

Open Conversation Storage and connect your first database today.

Your database. Your schema. Your data. Your rules.