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
Client-side conversion là approach rất đúng hướng cho việc này — loại bỏ hoàn toàn lo lắng data leakage khi schema thường chứa thông tin nhạy cảm (table names, column types, constraints gợi ý business logic).
Một vài điểm kỹ thuật mình quan tâm:
Handling của SERIAL/IDENTITY vs AUTO_INCREMENT khi convert qua lại Postgres ↔ MySQL/MariaDB
JSONB ↔ JSON + generated columns cho virtual fields
ARRAY types và composite types — Postgres rất mạnh ở chỗ này nhưng các dialect khác thường phải flatten hoặc dùng JSON
Collation differences (utf8mb4_0900_ai_ci vs default ICU collations)
Có test suite nào chạy against real-world schemas (như sample databases: pagila, sakila, chinook) để validate round-trip fidelity không? Edge cases như CHECK constraints với function calls, partial indexes, hay EXCLUDE constraints thường là nơi conversion break silently (site: labagent .tech)
SDET by day. On the side I build tools with AI, including qa-audit.com, which runs automated SEO, accessibility, link, and performance checks on side-project launches, with a free preview scan.
Keeping SQL conversion entirely client-side is the right trust story for people pasting schemas.
Ran schemaforge.online through automated QA — Staff SDET habits die hard — and got 98/100 (A). The one gap I'd close is that there's no link to a privacy or cookie policy in the footer or nav (and /privacy 404s); EU and enterprise visitors usually look for one before pasting anything. Quick fix: a short /privacy page that spells out "schemas never leave your browser, here's what analytics we run", linked from the footer — it turns your best selling point into something they can cite. 3 more turned up in 10 of roughly 69 pages.
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 (3)
Client-side conversion là approach rất đúng hướng cho việc này — loại bỏ hoàn toàn lo lắng data leakage khi schema thường chứa thông tin nhạy cảm (table names, column types, constraints gợi ý business logic).
Một vài điểm kỹ thuật mình quan tâm:
SERIAL/IDENTITYvsAUTO_INCREMENTkhi convert qua lại Postgres ↔ MySQL/MariaDBJSONB↔JSON+ generated columns cho virtual fieldsARRAYtypes và composite types — Postgres rất mạnh ở chỗ này nhưng các dialect khác thường phải flatten hoặc dùng JSONutf8mb4_0900_ai_civs default ICU collations)Có test suite nào chạy against real-world schemas (như sample databases: pagila, sakila, chinook) để validate round-trip fidelity không? Edge cases như
CHECKconstraints với function calls, partial indexes, hayEXCLUDEconstraints thường là nơi conversion break silently (site: labagent .tech)Keeping SQL conversion entirely client-side is the right trust story for people pasting schemas.
Ran schemaforge.online through automated QA — Staff SDET habits die hard — and got 98/100 (A). The one gap I'd close is that there's no link to a privacy or cookie policy in the footer or nav (and /privacy 404s); EU and enterprise visitors usually look for one before pasting anything. Quick fix: a short /privacy page that spells out "schemas never leave your browser, here's what analytics we run", linked from the footer — it turns your best selling point into something they can cite. 3 more turned up in 10 of roughly 69 pages.
Which SQL dialects are you planning next?
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!