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.
> I have to wonder if they’ve found it not worth the time to make it fully production ready.
It sounds like it's not compatible with all T-SQL commands and data types. It would be tough to get full feature completeness: Microsoft is constantly adding new stuff in each version, like the ability to run Java stored procedures, R & Python in the database, etc. Open sourcing it would let companies expand it to get specific features coded that they need - that otherwise might not get attention from the general public.
Correct. The focus is on 100% correctness. As I wrote in the post: "Over its 35 years in existence, SQL Server has evolved to meet a wide array of use cases. When first made available on GitHub, Babelfish won’t be able to handle every use case, but will be able to tackle the most common application scenarios. Most importantly, Babelfish will meet the correctness objective. That is, if Babelfish doesn’t yet support specific SQL Server functionality, it will return an error to the application, rather than defaulting to PostgreSQL behavior. Why? Because, again, developers (and the enterprises for which they work) must be able to depend absolutely on the correctness of SQL Server compatibility."
At launch Babelfish will be able to handle - with 100% correctness - the main semantics you'd want. HOWEVER, as you said (and as mentioned in the post), there's a large surface area, and a "long tail" of functionality that needs expertise from us and others to cover. So to do this right, it needs a community. It will be great for many use cases right from the start, but to ensure it's great/perfect for your use case...well, that just might take your help. Please work with us on this.
SCOTUS hasn't yet ruled on Google LLC v. Oracle America Inc. One imagines that if Oracle prevails in some demonstrative manner they may very well believe their flavor of SQL is a software interface protected by copywrite.
So will all the other 'software interface' owners of the world.
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.
Very good question, seems to be a strange decision. Maybe it doesn't meet what they deem up to the standards to include it in RDS due to the nature of how the backend is hosted (just a guess). Could be something as simple as the dependencies the extension requires are incompatible with what the RDS servers run. It would be very nice if the RDS team had some guidelines on what it takes to get an extension accepted for RDS with a good framework people can follow to ensure their extension complies with the security requirements, etc. Then have a way to submit an extension to be included and have it be reviewed and given guidance on any changes needed to comply (for a fee potentially).
At that point, thinking that SQL somehow is "portable" from a DB to another is a bit of a mirage. Way too many differences between systems, which does influence data modelling itself.
It feels like this is AWS fighting back with Microsoft after Microsoft raised fees to run SQL Server on AWS. Not only will AWS build this for themselves, but they'll contribute for anyone who wants it. That's a bigger blow to Microsoft than just facilitating migrations from MS SQL to pg in AWS; this impacts non-cloud-lifted database revenue.
>Those are the mechanics, but developers need to be certain that Babelfish truly speaks SQL Server’s language in a dependable, predictable way. As such, the guiding principle for Babelfish is correctness, with no compromises. What do I mean by correctness? Namely, that applications designed to use SQL Server semantics will behave the same on PostgreSQL as they would on SQL Server.
I am assuming they just mean in regards to types and the like - to get the same performance characteristics out of the code would be bonkers.
> 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.
It sounds like it's not compatible with all T-SQL commands and data types. It would be tough to get full feature completeness: Microsoft is constantly adding new stuff in each version, like the ability to run Java stored procedures, R & Python in the database, etc. Open sourcing it would let companies expand it to get specific features coded that they need - that otherwise might not get attention from the general public.