Tired of pasting schemas into random servers? I built SchemaForge: a 100% private, client-side SQL dialect converter. Translate schemas between PostgreSQL, MySQL, MariaDB & SQL Server locally in your browser. Link: schemaforge.online
If you have ever had to migrate a database or simply map table structures between different SQL engines, you know how tedious it can be.
Historically, my workflow involved either writing the translations by hand, using heavy desktop migration software, or taking a massive risk by pasting my raw schemas into random online formatters. The problem with online converters is that almost all of them send your data to a backend server. If you are working with proprietary company schemas, that is a huge privacy red flag.
I wanted something fast, completely private, and running locally in the browser. So, I built SchemaForge.
What it does
SchemaForge is a free developer utility that instantly translates SQL table structures between different dialects. You paste your schema on the left, select your target engine, and get the translated SQL on the right.
Currently, it supports conversions between:
PostgreSQL
MySQL
MariaDB
SQL Server
The Architecture: Strict Client-Side Execution
The main goal of this project was absolute privacy and zero latency.
Instead of passing user schemas to a Node backend or an external API, I wrote the parsing logic entirely in JavaScript so it executes natively in the browser.
The Tech Stack:
Framework: Next.js and React
Hosting: Vercel
Execution: 100% Client-side. You can literally disconnect from Wi-Fi after the page loads, and the converter will still work flawlessly. No database connections, no API payload sends.
The Tricky Parts
Handling the regex edge cases for different indexing syntaxes (especially the subtle differences between MariaDB and Postgres) was a fun challenge. Also, mapping the weird quirks between SQL Server's specific types (like DATETIME2 or NVARCHAR) to Postgres equivalents required a lot of manual mapping logic.
What's Next?
Right now, the tool handles the core SQL dialects, but I am looking at expanding its capabilities.
I would love to get your feedback! Try it out and let me know if you run into any parsing bugs. Also, what would be the most useful feature to add next?
Support for more database engines (SQLite, Oracle)?
ORM model generation (e.g., generating C# POCOs, Entity Framework models, or Prisma schemas directly from the SQL)?
Check it out here: schemaforge.online and let me know your thoughts in the comments!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Top comments (1)
If you have ever had to migrate a database or simply map table structures between different SQL engines, you know how tedious it can be.
Historically, my workflow involved either writing the translations by hand, using heavy desktop migration software, or taking a massive risk by pasting my raw schemas into random online formatters. The problem with online converters is that almost all of them send your data to a backend server. If you are working with proprietary company schemas, that is a huge privacy red flag.
I wanted something fast, completely private, and running locally in the browser. So, I built SchemaForge.
What it does
SchemaForge is a free developer utility that instantly translates SQL table structures between different dialects. You paste your schema on the left, select your target engine, and get the translated SQL on the right.
Currently, it supports conversions between:
PostgreSQL
MySQL
MariaDB
SQL Server
The Architecture: Strict Client-Side Execution
The main goal of this project was absolute privacy and zero latency.
Instead of passing user schemas to a Node backend or an external API, I wrote the parsing logic entirely in JavaScript so it executes natively in the browser.
The Tech Stack:
Framework: Next.js and React
Hosting: Vercel
Execution: 100% Client-side. You can literally disconnect from Wi-Fi after the page loads, and the converter will still work flawlessly. No database connections, no API payload sends.
The Tricky Parts
Handling the regex edge cases for different indexing syntaxes (especially the subtle differences between MariaDB and Postgres) was a fun challenge. Also, mapping the weird quirks between SQL Server's specific types (like DATETIME2 or NVARCHAR) to Postgres equivalents required a lot of manual mapping logic.
What's Next?
Right now, the tool handles the core SQL dialects, but I am looking at expanding its capabilities.
I would love to get your feedback! Try it out and let me know if you run into any parsing bugs. Also, what would be the most useful feature to add next?
Support for more database engines (SQLite, Oracle)?
ORM model generation (e.g., generating C# POCOs, Entity Framework models, or Prisma schemas directly from the SQL)?
Check it out here: schemaforge.online and let me know your thoughts in the comments!