Switch from MySQL to Postgres without changing a single line of code.
Your application was designed for MySQL, but NEXTGRES lets you run it on PostgreSQL with ease.
While PostgreSQL supports substantially more functionality than that required by applications designed for MySQL, differences in the client software, SQL dialect, and procedural languages often make switching databases a difficulty. Although a subset of these issues can be reduced using migration tools developed by third-party consultants and public cloud providers, they often require counterintuitive workarounds as well as changes to code and data types, which affect the overall behavior of your application. The substantial amount of hand-holding, tweaking, and testing involved in such a project is why switching databases is considered expensive and time-consuming. This is why NEXTGRES was created.
MySQL SQL Dialect
A large subset of the DDL and DML dialect employed by MySQL is supported. If an equivalent operation or option exists in Postgres, it is passed-through. Otherwise, it is dropped.
Native SQL/PSM Support
Unlike migration tools, which essentially translate syntax from MySQL to Postgres, NEXTGRES-based PostgreSQL has well-known MySQL functionality built-in.
Contrary to PostgreSQL, NEXTGRES supports native SQL/PSM using the freely-available PL/pgPSM (written by Pavel Stehule) – this means there is zero migration from SQL/PSM stored procedures to PL/pgSQL; your code moves directly over.
MySQL Protocol Compatible
NEXTGRES Gateway is a proxy which speaks the same wire-level network protocol as the MySQL. This enables applications designed to work with MySQL, including those without source code, to transparently interoperate with Postgres. Likewise, this enables developers and DBAs to use many of the same tools and utilities they’re accustomed to, such as MySQL Workbench, mysql-cli, etc.
How it Works
- Install NEXTGRES Gateway
- Enable MySQL Support
- Create a user/password for the MySQL client to connect as
- Create a MySQL listener for port 3307
- Add the user/password you created as an authorized user
- Enter the information for the target Postgres server the gateway will be passing queries to
- Update your connection information
- If this is a new install
- install your application as usual using the NEXTGRES Gateway in place of your MySQL server
- If this is a currently-existing application and you don’t have an easy way to install the schema from scratch or move the data:
- Migrate your existing data over to your target PostgreSQL server using a schema/data conversion tool
- Replace the MySQL server and user specified in your application’s connection information with that of the gateway
- If this is a new install
- Run your application
NEXTGRES Gateway acts as a man-in-the-middle network proxy: applications connect to the proxy and access database tables, functions, and procedures using MySQL-compatible SQL via standard MySQL connector programming interfaces such as libmysqlclient, JDBC, ODBC, etc. While the underlying tables and database objects actually exist in PostgreSQL, to the MySQL client, they are persistent, recoverable, and operate just as they would as if it were communicating with a MySQL server.
As a proxy, the gateway supports several installation methods: it can be installed on the server, on the client, or on a separate system between the client and server. Each installation location has its own pros and cons and the ideal installation depends on the architecture of your application and network.
- On-Server Installation – By installing the gateway on the database server itself, the gateway is able to communicate with PostgreSQL using UNIX sockets, thereby bypassing the TCP/IP stack, thereby reducing the latency and processing overhead required to convert data from PostgreSQL’s wire format to that expected by MySQL clients. This is ideal for cases where the server isn’t overloaded and network security doesn’t demand separation of the two.
- In-the-Middle Installation – Installing the gateway between the client and server is often found when users want to separate the proxy from the database and force all clients to connect through the proxy. As it’s not tied to the database itself, it also supports a linear-style scale-out to load-balance the proxy tier.
- On-Client Installation – Often referred to as application-tier database connection handling, this allows the client software to connect to the proxy locally, which also reduces the overhead associated with converting data.
Additional Compatibility Components
- MySQL Client Library Driver for ODBC – A drop-in replacement for the MySQL Commercial Connector/C client library, often referred to as libmysqlclient.
Pilot Customer Program
We’re currently piloting our product to a select number of customers. To be considered for the program, please send us an email.
We will soon be releasing a downloadable version of the product free for personal use. Stay tuned!