Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Babelfish: SQL Server-to-Postgres Translation Layer

aws.amazon.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#71

Post by dragonwriter »

beoberha wrote: post #2

Sounds like they’re open sourcing it to get some help on it. I have to wonder if they’ve found it not worth the time to make it fully production ready.

> Sounds like they’re open sourcing it to get some help on it.

My take is that they are open sourcing it because they don't just want to use it to compete with Microsoft to host SQL Server workloads on a better basis than Microsoft's licensing policy has let them in the past, but also to just undercut Microsoft's SQL Server licensing revenue generally.

As a business strategy, sure, but given the way everyone I've heard from AWS talks about Microsoft and SQL Server licensing, I wouldn't be surprised if there was a good deal of spite involved, too.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#72

Post by lukaseder »

etaioinshrdlu wrote: post #16

Don't hate me for it, but I'd like this for MySQL to postgres too. At least as a stepping stone. Use case: some of my SQL syntax depends on MySQL but I realize I made a poor life choice and would rather have transactional DDL and a myriad of better features on postgres.

Use https://www.jooq.org/translate/

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#73

Post by technion »

justizin wrote: post #67

i swear the fuck to god if one more piece of technology is called babelfish i am going to find out who is responsible and toilet paper their house.

I currently support the following products named "Integrity":

- Law firm management software - Document management software - A DVR appliance

Previously I supported HPE Integrity hardware. Certain names just seem way overused.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#75

Post by dragonwriter »

linuxhiker wrote: post #41
homarp wrote: post #31

Earlier quoted context omitted.

isn't that what enterprisedb is selling ?

Yes but it isn't Open Source.

Amazon acquiring EDB and rolling some of the currently-proprietary bits like the Oracle compatibility layer into open source Postgres while increasing resources to developing them could be an interesting play.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#76

Post by coredog64 »

dragonwriter wrote: post #71
beoberha wrote: post #2

Sounds like they’re open sourcing it to get some help on it. I have to wonder if they’ve found it not worth the time to make it fully production ready.

> Sounds like they’re open sourcing it to get some help on it. My take is that they are open sourcing it because they don't just want to use it to compete with Microsoft to host SQL Server workloads on a better basis than Microsoft's licensing policy has let them in the past, but also to just undercut Microsoft's SQL Server licensing revenue generally. As a business strategy, sure, but given the way everyone I've hea…

One word: JEDI.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#77

Post by Tostino »

rst wrote: post #18
temp667 wrote: post #12

Why not do this for Oracle? I've not found SQL Server to be too bad from the crazy Oracle stuff (light experience only - maybe bigger players have it worse?).

Oracle has peculiarities that you won't see in most other databases, which may make this a bit harder -- including such things as an oddball set of date/time types ("date" includes time to seconds), and treating zero length strings as SQL nulls -- '' is null evaluates to true in Oracle. It also has features like "fast refresh" on materialized views which might be tricky to emulate on other db engines. Nothing's impos…

Oh, immediate refresh of materialized views...its my biggest wish for postgres to have a seriously robust implementation.

I have some pretty complicated materialized views which the devs said would not work with their first implementation.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#78

Post by Tostino »

RegnisGnaw wrote: post #13
temp667 wrote: post #12

Why not do this for Oracle? I've not found SQL Server to be too bad from the crazy Oracle stuff (light experience only - maybe bigger players have it worse?).

As a DBA, T-SQL is much more standard then PL/SQL. Its probably step 1 of the plan, with step 2 being Oracle.

That's completely subjective and depends on your familiarity.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#79

Post by blendo »

throwaway201103 wrote: post #49
throw93 wrote: post #14

Earlier quoted context omitted.

About 10 years back my company hired consultants, spent close to 6 months translating SQL queries/stored procs to be Oracle. The goal was to support both MSSQL Server & Oracle for the on-premise product. It was quite costly undertaking. Then few years later they just abandoned Oracle because of maintenance costs. I wonder if anyone starting out today chooses Oracle as their relational database.

Oracle is very powerful. As a developer I found it easy to work with. But the cost to run in production is eye-watering. IDK how their licensing works today but in the past it was free to use for evaluation or for developing a prototype. Once you were "gaining business value" i.e. using it even if only internally to develop a real product, you were supposed to be paying for it.

Oracle XE is free for production use, but it only makes sense if

a) you are already familiar with Oracle, and

b) you have a very small data set:

“Oracle Database 18c XE supports up to:

3 Pluggable Databases

2 CPUs for foreground processes

2GB of RAM (SGA and PGA combined)

12GB of user data on disk (irrespective of compression factor)”

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#80

Post by victor106 »

lukaseder wrote: post #72
etaioinshrdlu wrote: post #16

Don't hate me for it, but I'd like this for MySQL to postgres too. At least as a stepping stone. Use case: some of my SQL syntax depends on MySQL but I realize I made a poor life choice and would rather have transactional DDL and a myriad of better features on postgres.

Use https://www.jooq.org/translate/

This is so awesome. Wish I found it earlier. Thanks for posting
Post reply on HN