# Polygres > Polygres is two tools. PolyWire is the intelligent gateway for Postgres: one secure, scalable > execution layer that lets Postgres, MySQL, Oracle, SQL Server, MongoDB, DynamoDB, Amazon SQS, > OpenSearch, gRPC, and MCP (AI agent) clients connect unmodified while everything actually > executes against one real Postgres database. PolyAdvisor is a rules-based (not LLM-generated) > tool that scores how hard migrating an existing database to Postgres will be, and PolyWire > bridges your application to Postgres while that migration happens. > > Protocol translation ("everything talks to Postgres") is one capability, not the whole product. > PolyWire's real category is "one control point for every Postgres workload." Frozen three-level > message: **PolyWire — the intelligent gateway for Postgres** (what it is) -> **Everything talks > to Postgres** (what's different) -> **One control point for every Postgres workload** (why > enterprises keep it running). One supporting line ties protocol support + security + QoS + > observability together: **different protocols, same policies, same Postgres**. > > Its full scope is five capabilities: **Connect** (ten client protocols, one Postgres backend -- > with live semantic execution translation, protocol to SQL/API semantics to PostgreSQL execution, > not just protocol framing), **Protect** (SQL firewall, connection ACL, authentication, row-level > security -- security follows the request, not the protocol), **Control** (QoS admission control, > routing, connection pooling, sharding, planned/unplanned failover), **Accelerate** (PolyCache, > rollups), 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, 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://polygres26.github.io/docs.html): every doc below, organized by what you're trying to do -- getting started, PolyWire, PolyAdvisor, and setup reference. ## PolyWire - [Main page](https://polygres26.github.io/#polywire): the pitch -- what PolyWire is, a live "see it happen" demo selectable per protocol (Oracle, MySQL, MongoDB, OpenSearch), a protocol-specific 60-second quickstart (Postgres/Oracle/MySQL/MongoDB/OpenSearch), the simple architecture diagram, dedicated QoS and security sections, a proof/compatibility stat strip, and pricing -- the detailed eight-stage architecture and the full comparison table sit one click deeper on the same page, collapsed by default under "Explore PolyWire in depth" (the standalone Oracle-modernization walkthrough was removed as redundant with the "Modernize databases" use case and the live Oracle demo, both already on the page). - [Full capabilities](https://polygres26.github.io/polywire.html): outcomes (organized by the five capabilities above -- Connect, Protect, Control, Accelerate, Observe), use cases, architecture, admin console, cache/RTT benchmarks per protocol, sharding, rollups, observability, multi-AZ deployment, security, error handling, and planned/unplanned outage handling -- 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://polygres26.github.io/oracle-to-postgres.html), [MySQL → PostgreSQL](https://polygres26.github.io/mysql-to-postgres.html), [MongoDB → PostgreSQL](https://polygres26.github.io/mongodb-to-postgres.html), and [OpenSearch → PostgreSQL](https://polygres26.github.io/opensearch-to-postgres.html). - [Connecting to your Postgres](https://polygres26.github.io/CONNECTING.md): worked examples and real gotchas for pointing PolyWire 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://polygres26.github.io/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: - Ten 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, 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, Oracle, and MySQL 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 -- PolyWire doesn't rewrite SQL to do this. - 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 protocols. - 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 POLYWIRE_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://polygres26.github.io/ERRORS.md) for the full per-protocol mapping. - MCP (Model Context Protocol) frontend: AI agents get real Postgres access through the exact same shared pipeline as every other client -- same SQL firewall, ACL, and QoS controls, not a separate, unguarded path to the data. - PolyCache: PolyWire's embedded, distributed query result cache, opt-in per table. 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. ### 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://polygres26.github.io/#pricing) on the main page for the full comparison, or [Contact](https://polygres26.github.io/#contact) to reach the team. ## PolyAdvisor PolyAdvisor plans the move to Postgres. PolyWire 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://polygres26.github.io/#polyadvisor): the bridge from the PolyWire pitch -- what PolyAdvisor is and a quick start. - [Full detail](https://polygres26.github.io/polyadvisor.html): 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. ## Common questions See the [FAQ section](https://polygres26.github.io/#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 PolyAdvisor's score LLM-generated). ## Contact Product questions, bug reports, and feature requests for either tool go through the [contact form](https://polygres26.github.io/#contact) on the main page -- no email address is published in plaintext anywhere on the site.