MSSQL is extremely, extremely capable as a database engine.

But it also costs an arm and a leg. People who haven't used it don't know just how capable it is.

plus they can take notes from Open source DB like postgress and improve their system better

When the client brought some 3rd party expert and he advised rewriting to MySQL, I quickly did the math and it was like $60/m, without a free year.

We continued with DTU MSSQL with Prisma ORM and never regreted.

The biggest problem with the usability of Microsoft products today is short-sighted thinking. New features, platforms, frameworks etc are launched and then forgotten about just a few years later with no effort to tie into the groundwork of what came before.

You might think this is only a problem for old customers who are already accustomed to the old technologies, but that's not true: it burdens new customers too. There's a few reasons for this that I can think of.

1) It's hard for new customers to know what technologies they should be reaching for in what situations when there's so many different choices.

2) It's hard to find the right documentation for the technology you've picked because you have to browse through a ton of out-of-date documentation that wrongly refers to the deprecated technologies and it's not clear what the current recommendations are.

3) The new stuff is often built without consideration for the ways of thinking that the underlying platform was built with. Thus, you end up with weird idiosyncrasies as you move from one technology to another, which make it hard to learn and hard to use.

4) When you replace the old technologies you lose the benefit of community knowledge on platforms like Stack Overflow, you lose the ability to look at existing open-source projects for guidance, etc. You are basically going into uncharted territory where there are no clearly established patterns in the wild.

So, even new users coming on to your platform suffer from these deficits. That's not to say I don't appreciate all the work on these new powerful technologies like VS Code and .NET Platform and so on, but I think a more long-sighted vision for these products would go a long way. And it's not just a matter of looking forward, since you never know what's going to happen in the future with a product as organizational priorities change. It's also a matter of looking backwards at what came before, at what groundwork was laid by previous efforts, and how it can be best taken advantage of and re-used for future efforts. That is the biggest missing piece at Microsoft today in my opinion.

It does not care if the imports are organized differently. I like to do:

   import (
      # standard libraries
      "fmt" 
      "io"

      # our stuff
      "github.com/pachyderm/pachyderm/src/internal/whatever"

      # packages
      "example.com/foo/bar"
      "github.com/whatever/whatever/foo"
   )

In my experience, DataGrip has been easier to get up and running out of the box and bringing the big IDE guns than DBeaver but DBeaver also does done this really well. For example I have never been able to setup DG with Access but DBeaver works pretty good out of the box with that garbage. Also it's free.

Both are solid

My company had some leftover Datagrip licences, and it felt like moving from notepad to an IDE. I haven't looked back since.

So you are saying that MIT/ISC/GPL/Apache2 and all the other OSS licenses do open you up to liabilites?

Not only that but it damages the reputation of this community.

You (<-- I don't mean you personally, but all of us) should be welcoming to new users and assume good faith, as the site guidelines ask (https://news.ycombinator.com/newsguidelines.html). There's no reason why you can't make your substantive points while doing so. (Edit: you needn't look far for a good example: https://news.ycombinator.com/item?id=44074135.)

It might also be good to remember that everyone makes mistakes, that project launches don't always go perfectly, and that HN is for discussing the interesting aspects of a submission.

— autocompletion for everything — table/function names, types; very helpful on projects with hundreds to thousands of tables

— navigation ("jump to referenced table", "find foreign keys to this column", etc)

— data export in two dozen formats (configurable)

— exactly the same UI for working with 30 database engines (or however many it supports, I'm too lazy to count). Especially helpful with databases that have atrocious CLI clients, like Oracle.

— a nice tree-structured view of your database; or you can generate a (possibly vector) diagram for the rare case when that helps

— high quality autoformatter that works for every SQL dialect it supports, and in the same way

— minor things like the ability to extract a subquery with a couple of key presses, or rename a table alias

Probably something else I'm forgetting.

Saving a couple of keystrokes when writing SQL has little to do with it.

`psql` is pretty bad at it and in `\e` you will just end up in an editor, which will probably don't know about your schema.

I've tried many tools, but seems like I like DataGrip (or databases in PyCharm Professional) the most, so I use EAP from time to time, when I'm going to write a lot of SQL.

Azure, Github, CoPilot, .NET (why do you think it is cross-platform), Java (yes, MS is back in Java land, they were the ones with initial ARM support), Go (they have their own FIPS compliant distro), Python (although with layoffs maybe not anymore), Rust, npm, Powershell, Powerapps, 365 AddIns, Teams plugins, clang/cmake (part of Visual Studio installer), Azure Linux, Sphere OS,....

Once you're gonna play with azure, GitHub, vsc, you're bit by bit invested in the ecosystem and opening the wallet for that other feature or integration.

If designed well - by suspending generation in memory and inserting a <function_result>, without restarting generation and fetching cache from disk - the round trip/tool call is better (costs the equivalent of 50 tokens for waiting + function_result tokens).

How do you keep that all in sync across your apps?

My first step was to look at the data using the UI. Then when I tested my queries, I also just ran them in the UI.

It’s just faster.

I never used the UI for “simple” queries since there wasn’t anything to test.