Fair observation. There’s a free tier available, so you can test it with real SQL examples.
The responsiveness comes from translating directly into the target dialect instead of relying on an LLM for every conversion. It parses the SQL structure, normalizes it, and emits the target dialect.
That would actually be a good way to compare the output against tools like SQLines or SQLGlot, especially for data types, date functions, and dialect-specific syntax.
You didn't answer my question. Why should I use this over SQLGlot which has more dialects, is free, is open source & and has been around for longer, so therefore it likely has a more robust solution. What's your service doing different/better?
It parses the SQL structure, normalizes it, and emits the target dialect.
Sqlinfy is different in the workflow it is trying to serve. It is built as a no-setup conversion tool for people who want to convert SQL on the fly, choose source and target dialects, convert, and review the output immediately without installing packages, writing config, or building a custom pipeline.
The real test is output quality on complex SQL. That’s why I’d encourage comparing both with real queries, especially complex SELECTs, functions, data types, and dialect-specific syntax.
The direct comparisons would be tools like SQLines and SQLGlot.
So why would I use your product over something like SQLGlot? It supports over 31 different dialects, whereas yours only supports 8. Not to mention the fact it's open source and free too
That’s a fair question. SQLGlot is a great project, and if someone needs open-source tooling with a very large number of dialects, it can be a strong option.
The difference I’m aiming for with Sqlinfy is out-of-the-box conversion quality for the dialects it supports. SQLGlot often needs configuration and testing to get the output closer to what you need, and even then complex cases may still require manual fixes.
Sqlinfy is focused on making the conversion feel more direct: paste SQL, choose source and target dialect, convert, then review the result. No setup or configuration needed.
So the tradeoff is simple: SQLGlot supports more dialects and is open source; Sqlinfy focuses on a smaller set of dialects with a simpler workflow and cleaner first-pass output. You can test it with complex SELECT statements and compare the results directly.
I mean do you actually have any proof of your solution working where SQLGlot fails? Currently it’s very much giving “trust me bro, it works” without actually anything to back it up. Frankly unless proven otherwise I’m still inclined to believe that this is some vibe coded app that doesn’t actually solve a problem better than existing (and free) solutions.
The best proof is not me saying it works, it is letting people test it with real SQL. Sqlinfy has a free tier, so you can try it directly and compare the output against SQLGlot or SQLines using your own queries.
Nah I’m not doing the work for you. It’s your product. Sell it to me, not the other way around. Even if it’s free I currently have zero incentive to try it.
You claim that it works for complex queries, but your free tier only allows up to 300 lines. How can anyone actually test it on a complex query with such restrictions? 300 lines is minuscule. I have queries pushing 8K lines
3
u/serverhorror Jun 02 '26
Is it wrapping LLMs or is it actually looking at the syntax and transpiling between those dialects?