27 comments

[ 3.5 ms ] story [ 70.0 ms ] thread
Migrate away from commercial database products to commercial cloud products. Why give away your money when you can give away your data too?
That's a salient point.

At the same time, the engineering and domain knowledge expertise required to pull this off is undeniably impressive.

This takes the ORM "compatibility promise" into new territory, maybe even a new stratosphere. Imagine if someone (or company) starts a comparable open-source translation extension layer targeting Postgres as the backend. That would be interesting!

Maybe start with the easier case of SQLite->Pg.

> Imagine if someone (or company) starts a comparable open-source translation extension layer targeting Postgres as the backend

That's what Babelfish is.

I wonder if orafce faced same type of comments after early releases.
(comment deleted)
encrypt at rest
Presumably the more realistic problem is having your data/business held for ransom by price hikes, not that AWS would jeopardize its reputation just to peek at your data.
Patches for postgres and extensions are available on GitHub. Anyone can build their own version of postgres with babelfish. It’s all licensed under Apache 2.0.
Wow it’s open source too!!
Even cross apply and info schema views, too bad, I used them a lot when I worked with sql server.
Some of these seem to be low-hanging fruit though, like NEWSEQUENTIALID() for example. Would be great to see which are likely to be implemented versus requiring major changes in pgsql to work.
NEWSEQUENTIALID() on SQL server generates a monotonically increasing GUID since last server restart, but monotonicity is not guaranteed between server restarts.

I am not aware of an equivalent function in postgres.

(comment deleted)
(comment deleted)
> we do not expect to support all functionalities right away. Instead, we focused on the most common T-SQL commands and returning the correct response or an error message

Well that sounds like it will be fun to wake up to. Do i have to worry about every windowing function to behave the same way or will there be "approximations".

As I read it, "correct response or an error message" does not include "approximations". Your app either runs on it or fails with an error. I assume many apps use quite a limited set of T-SQL features when going through Entity Framework, for example, and that's the market AWS is after.
If you’re using EF then just use the correct ADO.NET library and use native features - why use Babelfish with EF?
Well, in particular, the NPGSQL EF driver is pretty buggy. We frequently exhaust our connection pool and we don't even have a large database. Given the design of EF, it's difficult to see how we could possibly do anything different that would avoid exhaustion. It's a pretty vanilla setup.
> Given the design of EF

There's nothing about the design of EF that relates to how connections work: you can let the DbContext manage connections for you or can provide your own. (I assume you know that a DbContext is meant to be short-lived with a single owner) - so I'm very hesitant to say the issue is with EF's design or that the design of EF means you can't mitigate any issues with the PostgreSQL library for .NET.

Do you have a StackOverflow or GitHub post for this? I'd like to know more about this precisely because I'm thinking of switching from Azure SQL to Postgres for its superior data-modelling features (deferred constraints!)

I think the issue is that you cannot test 100% of your SQL queries the way you can with a compiled language.

What if there is an “if” branch taken 1 in 1000 times? You would not encounter the error during development.

(comment deleted)
Recent and related:

Open-Source Babelfish for Postgres - https://news.ycombinator.com/item?id=29031116 - Oct 2021 (28 comments)

Previously:

AWS Babelfish: The Elephant in the PostgreSQL Room? - https://news.ycombinator.com/item?id=26114281 - Feb 2021 (162 comments)

AWS Goes After Microsoft’s SQL Server with Babelfish for Aurora PostgreSQL - https://news.ycombinator.com/item?id=25276386 - Dec 2020 (10 comments)

Babelfish: SQL Server-to-Postgres Translation Layer - https://news.ycombinator.com/item?id=25267204 - Dec 2020 (113 comments)

This is an irony, moving from a proprietary database vendors to avoid lockin, to AWS that is virtually a locked in.

AWS tools makes it virtually a lock in and using the tool is even worse lockin.