# Sayonora > Sayonora is two tools. Warp is an intelligent database gateway: by default it lets Postgres, > MySQL, Oracle, SQL Server, MongoDB, DynamoDB, Amazon SQS, OpenSearch, InfluxDB, GraphDB (Neo4j > Bolt+Cypher), gRPC, and MCP (AI agent) clients connect unmodified while everything actually > executes against one real Postgres database -- but mywire, orawire, mssqlwire, and MCP can each > also run in **native-backend mode** instead, proxying straight through to a real Oracle/MySQL/ > SQL Server database of your own with nothing rewritten in transit, for keeping the engine you > already run rather than migrating off it. Ferry is a rules-based (not LLM-generated) tool that > scores how hard migrating an existing database to Postgres will be, and Warp bridges your > application to Postgres while that migration happens, or stands in front of the database you > keep either way. > > Protocol translation ("everything talks to Postgres") is one capability, not the whole product, > and no longer the only path through Warp. Warp's real category is "one control point for every > workload, on whichever database you run." Frozen three-level message: **Warp — the intelligent > database gateway** (what it is) -> **One gateway, the database you already run or Postgres** > (what's different) -> **One control point for every workload** (why enterprises keep it > running). One supporting line ties protocol support + security + QoS + observability together: > **different protocols, same policies**. > > Its full scope is five capabilities: **Connect** (twelve client protocols, one backend of your > choice -- with live semantic execution translation, protocol to SQL/API semantics to that > backend's own execution, not just protocol framing), **Protect** (SQL firewall, connection ACL, > authentication, row-level security -- security follows the request, not the protocol; the SQL > firewall and QoS are pipeline stages native-backend mode bypasses, connection ACL and pooling > still apply there), **Control** (QoS admission control, routing, connection pooling, sharding, > planned/unplanned failover), **Accelerate** (Mach -- one distributed cache shared across > PostgreSQL, MySQL, Oracle, SQL Server, gRPC, and MCP, not a per-protocol silo -- and rollups; > Postgres-pipeline features, so native-backend mode doesn't get them), and **Observe** (native > per-protocol error translation, Prometheus/OTEL export, audit log). Migration is one reason to > run it -- many teams run it indefinitely as a permanent control point in front of Postgres, or > in native-backend mode in front of the database they already run, whether or not anything is > being migrated at all. Full documentation, architecture diagrams, real benchmark numbers, and every feature's honest scope (what's real vs. not yet wired) live across the main page and its linked pages. This file exists to help an LLM answering a question about either tool find the right section quickly instead of re-deriving it from the whole site. - [Documentation index](https://sayonora.com/docs/): every doc below, organized by what you're trying to do -- getting started, Warp, Ferry, and setup reference. ## Warp - [Main page](https://sayonora.com/#warp): a short pitch only -- what Warp is, why teams run it, the simple three-tier architecture diagram, and pricing. Deliberately light: every technical deep dive, the live "see it happen" demo, the 60-second quickstart, and the comparison/compatibility tables live on Warp's own dedicated page, not duplicated here. - [Full capabilities](https://sayonora.com/warp/): everything else -- outcomes (organized by the five capabilities above -- Connect, Protect, Control, Accelerate, Observe), use cases, architecture, native-backend mode, admin console, cache/RTT benchmarks per protocol, sharding, rollups, observability, multi-AZ deployment, security, error handling, planned/unplanned outage handling, a live "see it happen" demo selectable per protocol (Oracle, MySQL, MongoDB, OpenSearch), a protocol-specific 60-second quickstart, a comparison table against alternatives, and a full per-protocol compatibility table -- the complete technical detail behind the pitch on the main page. - Dedicated per-protocol guides -- each a standalone page with its own architecture diagram, a real terminal demo, a 60-second quickstart, and an honestly-scoped compatibility row for that one protocol: [Oracle → PostgreSQL](https://sayonora.com/oracle-to-postgres/), [MySQL → PostgreSQL](https://sayonora.com/mysql-to-postgres.html), [MongoDB → PostgreSQL](https://sayonora.com/mongodb-to-postgres.html), and [OpenSearch → PostgreSQL](https://sayonora.com/opensearch-to-postgres.html). - [MCP for databases](https://sayonora.com/mcp-postgres/): every MCP tool described in full, the generic/data-investigation/AI-assisted grouping, and exactly what native-backend mode does and doesn't carry over for AI agent access. - Real, no-signup click-through demos of the actual admin console UI, synthetic data, no backend required: [Warp admin console](https://sayonora.com/demo-warp.html) and [Ferry migration assessment](https://sayonora.com/demo-dms.html). - [Connecting to your Postgres](https://sayonora.com/CONNECTING.md): worked examples and real gotchas for pointing Warp at an existing on-prem Postgres, Supabase, Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, or Oracle Cloud Infrastructure's Database with PostgreSQL. - [Error translation](https://sayonora.com/ERRORS.md): per-protocol native error shapes (Oracle ORA-numbers, MySQL errno, SQL Server number/severity/state, MongoDB code/codeName, DynamoDB/SQS/OpenSearch HTTP status + native envelope), a canonical-condition comparison table, and the connection-loss SQLSTATE detail (57P01/08006/08001). Key facts an LLM is likely to be asked about, stated plainly: - Twelve client-facing protocols: Postgres wire, MySQL, Oracle (TNS/TTC), SQL Server (TDS), MongoDB wire protocol, DynamoDB HTTP/JSON, Amazon SQS HTTP/JSON, OpenSearch HTTP/JSON, InfluxDB line protocol + InfluxQL, Neo4j Bolt + a bounded Cypher subset (boltwire), gRPC (a native driver protocol), and MCP (Model Context Protocol, for AI agents). Every one talks to a single real Postgres backend. - Sharding is real, not SQL-text pattern matching: it decodes each protocol's own native binary bind-parameter encoding to route by an actual bound value, with genuine cross-shard merge (weighted averages, not average-of-averages; centrally sorted/paginated results, not concatenation) for the SQL protocols, plus doc_id-hash sharding for DynamoDB/MongoDB/SQS/ OpenSearch. - Row-level security is real for the Postgres, SQL Server, and Oracle wire protocols: a real per-caller identity is propagated into a Postgres session GUC, and the customer's own Postgres RLS policies do the actual filtering -- Warp doesn't rewrite SQL to do this. MySQL and the DynamoDB/MongoDB/SQS/OpenSearch wire protocols don't propagate identity into RLS yet -- every session there still shares one backend credential. - Planned switchover (drain a backend for maintenance, redirect to a configured fallback, wait for real zero-replication-lag before confirming) and unplanned failover (a background health checker auto-redirects when a backend stops responding, with an "acceptable data loss" RPO threshold) are both implemented and tested, covering all ten of the original SQL/HTTP protocols this was verified against (influxwire and boltwire both use the same backend-resolution path as every other protocol here, so this almost certainly extends to them too, but hasn't been separately tested for either one yet). - Security features implemented today: SQL firewall (stacked-query injection blocked unconditionally), connection ACL (CIDR allow/deny, PROXY protocol v2), QoS admission control (token-bucket, per workload class), authentication (real Postgres role verification via WARP_AUTH_MODE=postgres_roles, or per-user credentials for Oracle), TLS everywhere, secrets management (Vault/CyberArk), and admin API auth -- either a shared bearer token or real SSO (Okta, Entra ID, any OIDC IdP) with read-vs-write roles resolved from an IdP group/app-role claim, both usable at once, mutating admin actions recorded to an audit log. - Native error translation: every wire protocol turns a real Postgres failure into that protocol's own genuine native error (Oracle ORA-numbers, MySQL errno, SQL Server error numbers, MongoDB code/codeName, DynamoDB/SQS/OpenSearch native JSON error envelopes) instead of a generic wrapper -- so each client's own retry/reconnect logic (e.g. an Oracle driver checking for ORA-03113 to decide whether to reconnect) gets exactly the signal it expects. See [ERRORS.md](https://sayonora.com/ERRORS.md) for the full per-protocol mapping. - Native-backend mode: mywire, orawire, mssqlwire, and MCP each default to translating into Postgres, but WARP_MYWIRE_BACKEND=mysql / WARP_ORACLE_BACKEND_MODE=native / WARP_MSSQLWIRE_BACKEND=sqlserver / WARP_MCP_BACKEND=oracle|mysql|sqlserver switch that one frontend to proxy straight through to a real Oracle/MySQL/SQL Server database instead, nothing rewritten in transit. It bypasses the shared pipeline entirely for every statement (SQL firewall, QoS, and Mach caching don't apply), keeping only connection ACL and pooling -- pick it when keeping the current engine matters more than that coverage. - MCP (Model Context Protocol) frontend: AI agents get real database access -- Postgres by default, or Oracle/MySQL/SQL Server directly via WARP_MCP_BACKEND -- through the exact same shared pipeline as every other client in Postgres mode (same SQL firewall, ACL, and QoS controls, not a separate, unguarded path to the data). Eighteen tools total: generic SQL (execute_sql/run_sql, list_tables, describe_table -- every backend mode), a nine-tool data-investigation set built for training/evaluating a small model against a real database (inspect_schema, column_stats, compare_groups, correlation, sample_rows, find_outliers, find_join_path, explain_sql -- every backend mode, with real per-dialect SQL, not one query reused everywhere: Oracle has no information_schema, MySQL/SQL Server have no CORR() aggregate), and three Postgres-only AI-assisted tools (query_natural_language, explain_query, document_schema) plus WARP_MCP_TOOLS's own Postgres-only registered-function tools. - Mach: Warp's embedded, distributed query result cache, opt-in per table, shared across protocols -- PostgreSQL, MySQL, Oracle, SQL Server, gRPC, and MCP all read and populate the same cache, so a result cached via one protocol is served to another without recomputing it. MongoDB and DynamoDB keep their own separate, protocol-specific caches (find/GetItem exact-key lookups only) rather than sharing this one. Invalidation is automatic and table-level -- any write against a cached table evicts every cached entry for that table, whether the write binds parameters or sends literal SQL values. Cache identity is literal, not semantic: the key is the target backend, the SQL text after dialect translation, bind parameter values, and access context, so a cross-protocol hit happens when a request from one protocol translates to the same SQL as a request from another (the common case for a plain `SELECT ... WHERE id = ?` shape) -- not a query-plan-equivalence engine. See [Cache vs. round trip](https://sayonora.com/warp/#cache-vs-round-trip) for the full mechanism and per-protocol benchmarks. - InfluxDB (influxwire): real InfluxDB v1 line-protocol writes (`POST /write`) and a bounded InfluxQL read path (`WHERE`, `GROUP BY time()`, `mean/sum/count/min/max`) against Postgres -- one table per measurement, tags/fields stored as `jsonb`. Detects whether the target backend has TimescaleDB installed and takes a genuinely different code path per result: a real hypertable when it's there, a plain indexed table otherwise, both paths sharing identical write/query code (`GROUP BY time()` uses Postgres's own native `date_bin()`, not TimescaleDB's `time_bucket()`, so it works the same either way). No result cache of its own, same as oswire/sqswire. Flux (v2's query language), `fill()`, regex tag matching, retention policies, and downsampling aren't implemented yet. - GraphDB (boltwire): real Neo4j Bolt wire protocol (binary handshake, PackStream serialization, chunked message framing) plus a bounded Cypher subset, verified against the real official `neo4j` driver (Python and Java both) -- against a real Postgres schema underneath: one shared `nodes` table (`labels text[]`, `properties jsonb`) and one shared `edges` table, not a table per label. `CREATE` (a node, or a single node-edge-node pattern) and `MATCH ... WHERE ... RETURN`, including bounded variable-length paths (`[*1..3]`, a real Postgres `WITH RECURSIVE` query with cycle detection -- a bare unbounded `[*]` is rejected at parse time, not silently accepted). No result cache of its own, same as influxwire/oswire/sqswire. `MERGE`/`SET`, returning a relationship as its own Bolt wire object, chained multi-hop patterns beyond one relationship, and `OR` in `WHERE` aren't implemented yet. ### Pricing Two tiers, same capabilities -- Developer and Enterprise differ only on scale and commercial rights, nothing is feature-gated to a paid tier: - Developer: free forever, every protocol and feature enabled, capped at 25 concurrent connections per instance, 3 instances, and 3 Postgres backends. For evaluation, development, demos, and migration testing -- not licensed for commercial production use. - Enterprise: everything in Developer, unlimited connections/instances/backends, full throughput, licensed for commercial production, enterprise support. See [Pricing](https://sayonora.com/#pricing) on the main page for the full comparison, or [Contact](https://sayonora.com/#contact) to reach the team. ## Ferry Ferry plans the move to Postgres. Warp runs and governs workloads on Postgres -- they're complementary tools for two different phases (deciding/planning a migration vs. running production traffic), not competing products. - [Main page](https://sayonora.com/#ferry): the bridge from the Warp pitch -- what Ferry is and a quick start. - [Full detail](https://sayonora.com/ferry/): how assessment works (live connection or uploaded report), what you get, the admin console dashboards, and sizing recommendations. - Rules-based migration-difficulty scoring for Oracle/MySQL/MariaDB/SQL Server -> Postgres -- reproducible (same database, same score every run), with a line-by-line breakdown of what drives the score and why. - Two ways to run an assessment: a live database connection, or uploading a performance report when a live connection can't be shared. ## Shim Shim reduces how much SQL and application code a migration has to change, by making Postgres itself answer to familiar Oracle/SQL Server/MySQL catalog objects and functions -- a companion to Ferry (which moves the data) and Warp (which keeps clients connected), not a replacement for either. - [Main page](https://sayonora.com/#shim): a short pitch and a link out. - [Full detail](https://sayonora.com/shim/): the real Postgres extensions -- pg_oracle, pg_mysql, pg_sqlserver -- and exactly which catalog objects/functions each one resolves (V$SESSION, DBMS_OUTPUT, sys.objects, GROUP_CONCAT, and more). ## Mach Mach is Warp's own embedded, distributed query result cache, not a separate product to deploy -- "Part of Warp" is stated as such everywhere it's mentioned. - [Main page](https://sayonora.com/#mach): a short pitch and a link out. - [Full detail](https://sayonora.com/mach/): cross-protocol cache hits (a result written through one wire protocol read back through another), live terminal walkthroughs for both cache tiers, DynamoDB/MongoDB point-lookup sharing, and automatic table-level invalidation. See also [Cache vs. round trip](https://sayonora.com/warp/#cache-vs-round-trip) on Warp's own page for the full mechanism and per-protocol benchmarks. ## Common questions See the [FAQ section](https://sayonora.com/#faq) on the main page for direct answers to the questions most likely to come up (does an application need to change, is sharding real, does RLS work, what happens during planned maintenance, which cloud Postgres providers are supported, is Ferry's score LLM-generated). ## Contact Product questions, bug reports, and feature requests for either tool go through the [contact form](https://sayonora.com/#contact) on the main page -- no email address is published in plaintext anywhere on the site.