I already blogged about it when it was announced on December last year [0]. Adding SQL Server compatibility opens Postgres to new users, use cases, markets. It makes one of the most general-purpose databases to reach even more "purposes".
I hope work and discussions to integrate this upstream will start soon and will be fruitful. It won't be easy, but I believe it would be definitely worth the effort.
[0]: https://www.ongres.com/blog/aws_announces_open_source_postgr...
I wonder if this will work for connecting to MS Access directly.
In a past job supporting an industrial controls firm, I wrote an interactive merge tool for AutoCAD Electrical parts catalog files (hideous little MDBs behind the scenes)...it was an unholy clusterfuck of C#, Lucene, NodeJS, and a smidgen of VueJS on the frontend. Not my proudest work, but it sure beat the usual tasks involving VBA in FactoryTalk.
Other comments on this suggest it's very important to them, which is a surprise to me.
Rather, I would have bet on either the performance characteristics for your particular situation, the knowledge of your programmers (or db admins) / recruitment pool, or perhaps integrations with other software.
Still, a very useful looking tool, don't want to knock it.
Also: I wonder if the shiny GUI tools that exist for MSSQL will then work from PG, and ... to what extend these tools will work with regular PG tables.
I really like DBeaver[1] (what I use myself), but I've seen stuff done by MSSQL DBAs using expensive GUI tools that have amazed me.
[1]: https://dbeaver.io/
Yes, it has a future.
The instruction for doing so is far from simple if you do not have a dev. background.
I look forward to using it. T-Sql is still the dialect I know best.
At $14K/core [0] for the Enterprise edition, it doesn't fit exactly on my definition of cheap. Sure, it's 1/4th of Oracle's price, but still translates to 6-7 figures for even small deployments, which again is not cheap to me.
But I guess the main attractiveness for current SQL Server uses might be more on the licensing terms/compliance problems than the cost. Just trying to understand how to license SQL Server and how cores are counted already requires you to read a 42-page guide [1]. The risks associated from incorrectly purchasing licenses for your SQL Server cluster(s) may be a compelling reason to jump into open source with minimal migration costs (at least compared to migrating directly to Postgres or any other open source database).
[0]: https://www.microsoft.com/en-us/sql-server/sql-server-2019-p... [1]: https://download.microsoft.com/download/e/2/9/e29a9331-965d-...
Licenses are sold in 2-core packs, so it's $7,000 per core. (The link you included is the 2-core pack pricing.)
> still translates to 6-7 figures for even small deployments
The majority of deployments are 8 cores or less [0], so even if they were Enterprise - which they're not - they're 5 figures. Not saying it's cheap, but it's an order of magnitude less expensive than what you're suggesting.
[0]: https://www.brentozar.com/archive/2020/03/sql-constantcare-p...
I think this is mostly for companies that run Postgresql, but need to bring in a single application which only supports SQL Server.
I wonder if you can make SQL Management Studio run against Babelfish.
Same was said for Lyenuks (Linux), Apache, etc.
You might be thinking of dblink in oracle's world, and foreign data wrapper (fdw) in postgres, which at least lets you transparently interact between the two for just DQL. DDL, procedural logic, etc definitely differs.
