Also like with dbeaver that you can take the results and export them in many different formats. like directly to excel for some of my co-workers who live and die in excel.
It seems like all their copilots are seperate subs, which seems like a missed opportunity honestly.
Quite amazing they put the effort into this for Postgres instead of SQL Server. The demand must be a lot higher.
ADS is being sunset, and I was surprised when trying to install the Postgres extension on VS Code to find that it had its last meaningful contribution 6 years ago [0]. It couldn't work on newer VS Code versions.
I use ADS with both Postgres and MSSQL, prior to this announcement, I kept using ADS because there was nothing to migrate to.
[0] https://github.com/microsoft/vscode-postgresql/commits/maste...
You can find workarounds, but it is an awful situation. Now the community is probably going to have to re-fork the library back to the public for maintenance.
I am clearly not a bean counter, but if Microsoft wants its database to win against the free options, they could do their best to ensure popular libraries can seamlessly connect.
https://github.com/microsoft/mssql-django/issues/418#issueco...
We’re still working on bringing over some Azure Data Studio features to the VS Code extension, especially around import/export (like flat file and DACPAC). I’d love to hear what else you think is missing.
If you’re interested, here’s our open roadmap: https://aka.ms/vscode-mssql-roadmap
I'm assuming they might want to move SSMS to VSCode in time, so trying it out by covering new ground, PostgreSQL, makes sense to me.
[1]: https://learn.microsoft.com/en-us/ssms/sql-server-management...
https://learn.microsoft.com/en-us/archive/msdn-magazine/2005...
They were really well designed, incredibly snappy and responsive. When SSMS was launched it was really slow and clunky on my computer.
I switched to Postgres around that time so I'm 20 years out of touch at this point.
We’re actively working to improve the experience, and learning what works for you in SSMS would be incredibly valuable.
As I’ve mentioned in a few other threads, the PostgreSQL team recently forked our MSSQL extension to kick off a fresh implementation for Postgres. It’s built on the same foundation we’re actively improving and evolving for both extensions.
See here for the SQL server extension: https://marketplace.visualstudio.com/items?itemName=ms-mssql...
Just to clarify on the Azure Data Studio (ADS) point: the MSSQL extension includes many of the core features from ADS, but our strategy is slightly different and focused on a modern, developer-first experience.
Here’s the link to our open roadmap—would love to hear your thoughts: https://aka.ms/vscode-mssql-roadmap
But they charge you an arm and a leg for the pleasure, but it can be worthwhile for enterprise.
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.
The reason people don't use them more often is that they're not free or even inexpensive.
plus they can take notes from Open source DB like postgress and improve their system better
that's every SQL server out there included Postgres. Is NoSQL considered as none-legacy?
I've helped create apps that support millions to hundreds of millions of revenue on Azure SQL Databases that cost at most a few hundred dollars per month. And you can get started with a S0 database for $15/mo which is absolutely suitable for production use for simple apps.
Unfortunately, I think Microsoft realized how good of a value the DTU-based model was, and has started pushing everyone to the vCore model, which dramatically increases the barrier to entry for Azure SQL Database, making PostgreSQL a much more attractive option. If Microsoft ever kills off the DTU purchasing model of Azure SQL Database, I likely won't be recommending or choosing Azure SQL Database at all going forward. It'll 100% be PostgreSQL.
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.
From a consumer perspective, we're almost all benefiting.
From a business perspective, they get unpaid help and community brownie points.
Given that there are many Microsoft closed source extensions for VS Code, that cannot legally be used with the open source Version of VS Code, I would say they are not going all in. Knee deep maybe.
[0]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
Microsoft isn't "sincere" because it's just a business doing what businesses do, making money. They're not trying to be altruistic or principled. They're just doing business.
But I have personally benefited from this deal by having TypeScript and VS Code at my disposal.
Can you point out such recent behavior that isn't just echoing other peoples opinions from the anti-trust case from over two decades ago? It's been my experience that many people seem to "borrow" their opinion about Microsoft from things they've read rather than personal experience so we keep getting the same low-effort criticism ad nauseam.
Point to this marketing. Here's the blog announcement on the 1.0 releases - what I can't find are any examples of Microsoft over-promising.
https://web.archive.org/web/20160422123116/https://code.visu...
> MS locked things down... and MS has artificially prevented vscode forks from using those extensions
Or like any growing and maturing project they established boundaries - one of which was that the plugin marketplace was proprietary, which is a perfectly reasonable position. Their existing and continued contributions to vscode are significant, so I think they can be allowed to keep some cards up their sleeves like the plugin marketplace or their Python extension. I'm just flabbergasted at this idea that somehow we're entitled to everything vscode-adjacent "just because", or that Microsoft is obligated to subsidize other billion-dollar business by giving them free features for their vscode forks.
> A bait and switch if I've ever seen one.
Where's the bait? Where's the switch? If the best you have is that they released a closed source plugin I'm going to bucket this as another borrowed opinion.
It would have been fine if MS had started with their Python extension being proprietary, that would have been up front and transparent. Instead, they lured folks in (no small part due to open source), and once it became popular, they started turning the screws and making things proprietary and locking it down.
> I'm just flabbergasted at this idea that somehow we're entitled to everything vscode-adjacent "just because"
You're not arguing in good faith at this point. I don't think it is unreasonable to ask someone to make their intentions known up front do you? Instead MS waited until vscode became popular (partly because everything was open source) and then altering the deal Vader style closing off parts of vscode and extensions that were open. That doesn't feel particularly transparent.
> or that Microsoft is obligated to subsidize other billion-dollar business by giving them free features for their vscode forks.
I have no idea what you're talking about here. Vscodium is an entirely free and open source fork, no one makes any money from it afaik.
> Where's the bait? Where's the switch? If the best you have is that they released a closed source plugin I'm going to bucket this as another borrowed opinion.
They released the Python stack as fully open source. Then released the proprietary one, deprecating the open source one. Then made double certain that vscodium or any of the other forks could not use it at all, even if the use manually downloaded the extension. How is that not a bait and switch?
Except that never happened. Pyright was released first and was and continues to be open source. Pylance was built on Pyright but has never been open source. No promises or commitments were made otherwise. Deprecating the open source Python Language Server in favor of Pylance is also a perfectly reasonable and valid decision - the community was more than welcome to continue maintaining it, but most people I know continue to rely on Pylance.
> Instead, they lured folks in
Saying this doesn't make it true.
> Instead, they lured folks in (no small part due to open source), and once it became popular, they started turning the screws and making things proprietary and locking it down.
Microsoft has not once backtracked on anything vscode-related that's been open sourced. Trying to villianize them for not making everything open source is an argument with no legs.
> I don't think it is unreasonable to ask someone to make their intentions known up front do you?
They have. Point me to a single actual example of Microsoft operating in bad faith, that isn't them deciding to keep some parts of the ecosystem proprietary while 99% remains FOSS.
> Vscodium is an entirely free and open source fork
Microsoft and the vscode team is not making long-term decisions with vscodium in mind. But they are probably worried about Windsurf and Cursor, the latter of which (a billion-dollar company) was caught violating MS's TOS around the plugin ecosystem.
Microsoft has spent over a decade investing in, curating, and improving the vscode first-party plugin ecosystem and being a rather good steward. I think they're perfectly reasonable in keeping it to themselves. Creators are free to upload their plugins to any alternative marketplace. I don't see any arguments being made that can diminish the open source contribution they've made with code - oss just because parts of the branded vscode are proprietary.
> They released the Python stack as fully open source.
Again, no they didn't. Pyright open source. Pylance always closed source. PLS deprecated. But you're entitled to what you borrowed.
No, the first Python extension that shipped with vscode 1.0 in 2016 was called the "Microsoft Python Language Server" and was based on the Jedi LSP. Below is the deprecation announcement of the Jedi language server in the Pylance launch post below.
> In the short-term, you will still be able to use the Microsoft Python Language Server as your choice of language server when writing Python in Visual Studio Code. > Our long-term plan is to transition our Microsoft Python Language Server users over to Pylance and eventually deprecate and remove the old language server as a supported option. https://devblogs.microsoft.com/python/announcing-pylance-fas...
> But they are probably worried about Windsurf and Cursor, the latter of which (a billion-dollar company) was caught violating MS's TOS around the plugin ecosystem.
If that were so, I would certainly understand. However, MS started closing vscode and the extensions years before Windsurf and Cursor (initial release in 2023). This was their business model all along get adoption in partly by leveraging the open source community, and then close things off slowly once they have a choke hold (similar to Android/AOSP). I could scarcely agree more that Windserf and Cursor are supremely sketchy and generally scummy companies.
Consider MS launch announcement that focuses on open source, extensibility, open community, and a promise to be transparent with their intentions (i.e., vision) and roadmap...
> From the beginning, we’ve striven to be as open as possible in our roadmap and vision for VS Code, and in November, we took that a step further by open-sourcing VS Code and adding the ability for anyone to make it better through submitting issues and feedback, making pull requests, or creating extensions.
https://code.visualstudio.com/blogs/2016/04/14/vscode-1.0/#_...
Except they weren't open and did a u-turn on the community a few years later. MS started closing sources and locked things down a few years later despite touting the benefits of being open and open source in the announcement above. Now they have architected the Python extension so it only runs on vscode, and will not run at all on any fork, which is pretty shady after promising transparency and openness.
> The new, free language server
Pylance isn't the same extension as what was originally shipped, it's an entirely different product. Your link backs up my argument, not yours. Releasing an open source project doesn't not obligate them to continue supporting that project indefinitely, and the decision to migrate to a closed-source plugin is a perfectly valid and reasonable decision. Disagreeing with it doesn't mean they've somehow magically violated some implicit obligation you think they owe "the community".
> MS started closing vscode and the extensions years
They never "started". The plugin marketplace and vscode - the proprietary version of "Code - OSS" - has always been proprietary and closed. At no point did they give you something and take it away. Deciding to release a closed-source replacement for an open-source tool is not the same thing, and it's bad faith to argue otherwise to fit your fundamentally flawed argument.
> This was their business model all along get adoption in partly by leveraging the open source community
>Consider MS launch announcement that focuses on open source, extensibility, open community
You're relying on hand-wavy assertions without any evidence to back it up.
> Except they weren't open and did a u-turn on the community a few years later.
Where's the u-turn? I don't see anything in this post that's not true in 2025. Microsoft offers a curated plugin marketplace that's proprietary to vscode, and they provide distribution and hosting for free without requiring anything from creators and users. Pylance continues to be free but closed, Code - OSS continues to be FOSS, vscode continues to be a proprietary version of Code - OSS, plugin authors continue to upload products free-of-charge, and users continue to benefit from that community that Microsoft has fostered.
They've firmly established what their role is in this relationship. There's never been ambiguity between what's vscode closed-source and what's code - oss, unless you've not put in the effort to find out.
Point to an actual, concrete example of where they've acted in bad faith, did a "u-turn", or reneged on a public statement rather than hand-wavy generalizations. It's on you if you've relied on second-hand HN comments and news headlines to build your opinion, and relying on misunderstanding of context isn't a convincing argument.
Personal experience is irrelevant if the facts are not in doubt. One of these is that Microsoft was a pretty bad actor when nobody reigned them in, and I was around at the time.
> One of these is that Microsoft was a pretty bad actor when nobody reigned them in, and I was around at the time.
So was I (was working in Redmond at the time), and their behavior was no worse than what Apple or Google are up to today. The anti-trust case itself was 90% theater, Microsoft was let off with a slap on the wrist but somehow popular culture has decided it was much more devastating than it really was because it reinforces their "M$ bad" bias. It's hard for me not to chalk comments like this to the "borrowed" bucket rather than researched and well-informed opinion, and it just convinces me further than when it comes to Microsoft people are borrowing their opinions rather than earning them.
Yes, Microsoft made some dick moves over 25 years ago and paid for it. They continue to operate like every other business in 2025 despite being the largest company in the world by market cap. At some point folks can't keep pulling up this card like it's a wildcard-win-all.
In my opinion, Microsoft wants the good vibes and PR that comes with open source, but they don't actually want to be open source. Its why many people still don't trust them in this arena.
Yes, Microsoft has an history, yet it isn't as if there is any big corporation doing full open source across all their products, the large majority only does the part that somehow brings good vibes, cuts down their own R&D costs, or is a kind of suble way to find out about possible new employees.
Both teams seem to very much want developers to enjoy their tools, so please do send them feedback on what you need out of the tools.
Follow Carlos Robles if you want SQL server extension news: https://www.linkedin.com/in/croblesm/
Follow Joshua Johnson for PostgreSQL server extension news: https://www.linkedin.com/in/johnsonjoshuae/
Not to mention that SQL "SDK-style" projects only work properly in VS Code, so Visual Studio users are left out in the cold having to deal with an incomplete, half-baked solution.
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.
Feel free to connect with me on LinkedIn, and we can go from there: https://www.linkedin.com/in/croblesm/
Feel free to connect with me on LinkedIn, and we can go from there: https://www.linkedin.com/in/croblesm/
Embrace, extend, extinguish.
no source, not a promising privacy policy
Good starting point: https://www.jetbrains.com/pages/intellij-idea-databases/
That's cool. How do I get this into JetBrains IDEs?
JetBrains has always done their completion / language integration differently than VSCode + LSP, but it seems to work well. My only complaint is that GoLand organizes imports differently than gopls / goimports, but my knowledge there is a few years out of date. I've worked on teams with a lot of GoLand users and nothing has really bothered me on this front recently, so they probably fixed it years ago.
Yes, Intellj will recognize that the string in my code is an SQL statement and use auto complete and validation when it is connected to a database.
I've looked at the announcement and it seems that the functionality of Jetbrains is similar.
One benefit of using VSCode/Sublime Text/vim/emacs language integrations is that I roughly know what command to run to get the same results in the terminal as I get in the editor. With JetBrains does-it--all IDEs, I have no clue.
[0] https://www.jetbrains.com/help/qodana/getting-started.html
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"
)
The main difference is that JetBrains supports a bunch of databases, not just one.
(I thought it was particularly nice when you could install most to the VS Code DB extensions standalone as "Azure Data Studio"; you can build separate VS Code profiles for your coding and DBA hats of course, but it's not quite the same feel as launching a separate, dedicated application. Though "Azure Data Studio" was often overlooked because it worked just fine on non-Azure hosted databases.)
I much prefer JB's git integration, but I wouldn't discount it just because the UI is so completely different.
I don't want to poop on open source, but pgadmin and dbeaver and not even close to playing in the same league.
I work in Oracle and Datagrip saved my sanity.
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.
I think it's worth downloading the 30 day trial and giving it a quick whirl. The people who dislike it seem to get hesitant quite quickly, so I doubt you'd need more than a day to decide if it's for you or not. There are all kinds of cool and fancy plugins you can set up, but I wouldn't bother with that if you decide the UX just isn't for you.
It supports quite literally every database I've thrown at it, which is pretty nice.
The way it support projects is also rather useful to me as a developer. Most SQL tools seem to be focused on being an interface first and maybe having a few SQL files open second, but Datagrip's basis as an IDE makes it very easy to maintain collections of scripts (version migrations etc).
That said, I'm not sure if the 99 bucks (a year if you want updates, though you get a perpetual license for the current version) is worth it. I use it because it's part of Jetbrains' all products pack, which I paid to use other IDEs, essentially giving me Datagrip for free. If you're not already a Jetbrains customer you could definitely give it a go, but the value per dollar it provides is very different.
As you suggest however, tooling for that workload is pretty rare. I want something that focuses on enhancing the database development experience: that understands that there are development workflows for database code which are well controlled and rigorous. So many database tools are focused on being system administrative aids first, or giving you features for directly interacting and <ack> altering the running state of the database and its server from the tool.
The best tool I found for what I do was targeted at Oracle: Allround Automation's PL/SQL Developer (https://www.allroundautomations.com/products/pl-sql-develope...). It's a development oriented tool that, at least last I used it, was focused on serious development work rather than administrative work. Now, I haven't used it in almost 20 years when last I did Oracle development... but I haven't found anything for PostgreSQL that has that thoughtfully implemented database developer centric feature set.
Today I muddle through with DataGrip. DataGrip has just enough of what I need that it's marginally better to work with than just a simple text editor... and also narrowly avoids some misfeatures as not to negate it's utility.
I loved workgroup style app development. R:Base, Access, dBase, FoxPro. Then I switched to UI work for a stretch.
Circling back to back-end work, naive me embraced Hibernate (2004?), assuming it'd be familiar and good.
I was wrong.
Now that I have a lot of free time, I'm finally recreating the workgroup style experience, for the general dev population. Sort of.
Using Hibernate, our workflow became: rough in some ORM hack, capture the generated SQL, use SQL Query Analyzer and Toad to make it work (and performant), coerce Hibernate to regenerate the SQL we want. Totally backwards, right?
Eventually we gave up and just used HQL.
At that point, why even bother with ORM?
So I created a "SQL first" workflow. Treat your SQL (DML) as source code, use those explicit queries to generate the prepared statements (and typesafe DAOs, DTOs, etc). In other words, auto-generate all the things you'd do yourself, if only you had more time.
I used my tool for years. Am currently making it usable for other devs. eg Spent last week making my grammar for MySQL "good enough" for initial release. Already have PostgreSQL and SQLite, plus my original turrible "poor mans SQL" grammar (comparable SQL-92). Which I'll cull once I have "good enough" T-SQL and PL/SQL grammars.
Any way. Thanks for reading.
I only meant to confirm your experience with development DBAs. The only such person I was able to retain was near retirement and was tired of the hustle.
> The software is licensed, not sold. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you will not (and have no right to):[…] d) use the software for commercial, non-profit, or revenue-generating activities
Oops. Better not install this on your work laptop!
[0] https://marketplace.visualstudio.com/items/ms-ossdata.vscode...
Edit: That's uncharitable of me. I strongly doubt that's the plan. But it genuinely was the first thing that came to mind.
Its a public preview, for which Microsoft probably does not wish to accept non-disclaimable liabilities for defects when used in those circumstances.
It is for previewing. By people who are interested in what is in the pipeline for a more general release.
So you are saying that MIT/ISC/GPL/Apache2 and all the other OSS licenses do open you up to liabilites?
This may also, to a lesser extent, be true of people who are not merchants in the field of the product supplied.
It’s not the license creating the liability, in either case.
"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
do not constitute something that frees you from those liabilities?
Cause if so I think basically most of open-source would just shut down tomorrow.
You cannot effectively disclaim certain liability for uses of a product you supply, even with an as-is presentation (exactly what liability depends on jurisdiction and often other context). Merely claiming to have no liability does not make it so (what it will usually do is disclaim all yhe liability you can disclaim, except for particular liabilities that may require separate explicit specific waivers to be effective.)
OTOH, if the product you provide is a software license that doesn't cover specific uses, using the software for the excluded uses may not be seen as a use of the product provided at all, and may not trigger the non-disclaimable liabilities, and even it doesn't avoid those liabilities, in the event someone sues over them, it also enabled the product supplier to countersue for infringement damages and mitigate the liabilities.
Why would they spend money into this extension if 99% of developers can't use it?
Is MS going to be a jerk about it? Almost certainly not. Could they if they wanted to? Sure seems like it.
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
If it helps at all, there's also this: "Assume good faith" - https://news.ycombinator.com/newsguidelines.html
Yes they are a new user, but they appear to have made the account just to make that comment.
People making accounts so they can talk about their work is one of the best reasons for people to make an account and a big part of what makes HN threads interesting.
people claiming to be official advocates that could do real damage to your company if legal wanted to bone you.
That seems like the opposite of assuming good faith.
Uhuh but coming in to give bad legal advice as your first comment for the benefit of the largest most litigious corp on the planet, is that what makes HN threads interesting?
> That seems like the opposite of assuming good faith.
That wasn't a statement towards the individual. That was a statement of what could befall someone who took their advice.
That wasn't a statement towards the individual. That was a statement of what could befall someone who took their advice.
No, I don't think that's true - it's just a catastrophizing rationalization for reflexive dickishness. We all suffer from reflexive dickishness so of course it happens and it's not that big of a deal but trying to pass it off as some sort of virtue is a mistake.
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.
I'll acknowledge that kstrauser may have done a better job of sounding friendly about it, but I don't think my question was out of line nor even particularly aggressive given the circumstances.
That is a huge overstatement that you can't really use to justify the haranguing. They just popped in to address the potential issue and let people know they're trying to sort it out. Nobody is giving legal advice and nobody is going to end up in legal trouble because Microsoft messed up their license boilerplate for a bit.
You may not have meant to be haranguing, but intent doesn't communicate itself—at least not in the tiny textblobs which are all we have here. It has to be included in the message.
When I look at your comment from that point of view, I notice that it leads with a hostile personal trope ("You do recognize...?"), followed by a putdown of everything this team is probably hoping for ("no one should use this"), followed by a personal attack ("you shouldn't be encouraging"), followed by a pedantic hammer-blow ("legally the license is the license") that takes the spotlight away from anything new or exciting about their work. That is followed by a sentence that basically shames them for what was obviously just an oversight. How is a newcomer (or anyone, for that matter) supposed to feel when they encounter that?
You're a good HN member and I'm sure you didn't intend to condemn or humiliate anyone. The problem is that people routinely underestimate the provocation in their own comments and overestimate the provocation in others'. If the error is 10x in each direction, that's a huge skew [1]. That's why it's hard to track the impact that one's posts have—especially the righteously indignant sort of post [2].
I suppose one of the moderators' jobs is to step in and try to articulate that explicitly, in the hope of persuading enough users to generate a bit of a system correction.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[2] which, by the way, I can feel a bit of in my own comment just now, and I'm probably underestimating it too.
Are you authorized to do the same on a blog hosted on microsoft.com? A lot of people would treat that as authoritative even if bigger enterprises will wait for the shrink-wrap to be updated.
Good: "Your honor, here's a copy of their official blog where they said the license terms are a temporary glitch but that we're fully allowed and encouraged to use the product."
Not good: "Your honor, an anonymous new account on Hacker News said it's totally fine to use this even though the license forbids it."
I'd cheerfully take my chances with the former. The latter? Not so much.
(As mentioned elsewhere, I don't for a second think MS is going to track me down and sue me for using this against the terms of the license. I'd feel a whole lot better if someone officially put that in writing, though.)
Data grip for big serious stuff.
It makes me wish for something like phpmyadmin or adminer
I guess not everything needs to live inside my IDE
— 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.
- neovim for file editing,
- zsh (+zoxide) for navigation / file management,
- plain git to manage my repos,
- plain text note taking and accounting, etc.
There are tons of enterprise development workflows, and plugins, that probably will never be ported into VSCode, from their .NET and COM implementations.
Now in terms of mindshare, and gateway drug into Microsoft ecosystem, definitely VSCode.
It is also the best Web IDE, for the return of timesharing development, sorry cloud.
That alone means everyone that is on Github and Azure, gets to use it as the modern version from X Windows and RDP/Citrix sessions.
Not bad, for Eclipse v2 (Enrich Gamma is one of the main architects), pity the whole Electron shell though.
FWIW I use it via Linux .deb and integrate with a private GitLab.
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.
Also the best webdev IDE.
I'm an emacs user and even I keep a copy of VSCode installed just because I occasionally have to interact with SQL Server and it's really the best way to do that on non-windows systems now that they're winding down ADS.
When was that?
It is becoming common for some to use Rider primarily, but VS is still used as part of the build system.
It was never marketed like that, for the simple reason that popular VSCode languages like Python/HTML/Javascript were never well supported by regular Visual Studio, so there is no way to move to "proper" Visual Studio if you do Python/web development.
Check it out and get on the waitlist getgalaxy.io/explore/product-tour
happy to chat live with anyone if interested, support@getgalaxy.io
Not a good way to generate potential user interest or generally good feelings towards it.
Just saying.
We're going to be rolling out Prisma Studio as a VS Code extension soon!
Maybe it's because my tolerance for imperfection is much lower for databases than web apps, but it is so bad that I can't trust it for anything database-related beyond text transformations and generating boilerplate queries. It will incorrectly tell me things like postgres doesn't support TABLE OF <TYPE>, or make syntax errors for ON CONFLICT, and immediately agree with any "what about" or "are you sure" I throw at it.
Curious if anybody else has run into this. Obviously LLMs are not always great in specialized domains like this but the poor performance with something as popular as postgres is pretty uncharacteristic IMMO.
I'm not sure whether or not it's better to have your editor database-aware or to have your codebase have appropriate context committed. On one hand, less generated code/artifacts make for a cleaner codebase. On the other hand, not everyone uses VC Code or will know how to use this integration. Database browser GUIs have never really had a single winner. That said, VS Code does have enough dominance to potentially make themselves "the standard way to view a database in development"
I'm curious, do you output triggers, store procedures, and such? Many tools seem to stop after you've defined tables, columns, and indices, but I'd love some better tooling to make use of the rest of the DB's features.
And curses. Now I'm going down another rabbit hole rehashing ways to interface with my database in a side project that is doomed to never get past the "there has to be a better way to…" phase ;)
You're adding a round trip to the database and the LLM and inserting a tool call in the conversation before it even starts generating any code.
And the reference Postgres MCP implementation doesn't include Postgres types or materialized views, and is one of the most widely used packages: Zed.dev's MCP server for example, is seemingly just a port of it and has the same problem.
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).
And you don't have to wonder about "if designed well": the reference implementation that's getting 20k downloads a week and getting embedded in downstream editors is is not designed well and will make the round trip every time and still not give the LLM the full information of the table.
Most MCP implementations are crappy half-assed implementations in similar fashion because everyone was rushing to post how they added <insert DB/API/Data Source> to MCP.
And if you're worried about "context fatigue" (you mean LLMs getting distracted by relevant information...), you should 100% prefer a well known schema format to N MCP prompt definitions with tool usage instructions that weren't even necessarily tuned for the LLM in question.
LLMs are much more easily derailed by the addition of extra tools and having to reason about when to call them and the results of calling them, than they are a prompt caching friendly block of tokens with easy to follow meaning.
How do you keep that all in sync across your apps?
By “don’t do it,” I mean having multiple apps talk to one DB schema.
Services are slow, restrictive, and don't enjoy the benefits of an actual DBMS, like transactions. You also add additional dependencies and failure points.
All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates.
As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reason for what you're proposing.
1. DB -> App = Two updates, the schema and the app
2. DB -> Service -> App = Three updates, the schema, the service, and the app
In both cases, obviously the DB changes.
In both cases, obviously the App changes.
In the second case, you also get to update your services.
The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.
Literally everything you just said applies to services and API contracts as well. You haven't solved anything.
> the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed
You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.
"Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.
I'd work to fix the communication problem before I adopted a terrible tech solution.
> You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.
What you wrote isn't a contradiction of what I wrote. I wrote "more understood" not "perfectly solved problem."
> "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.
Except they are because the tooling is better. I can check calls to an API endpoint using the same tooling that I would for checking end user API calls. I can push out comms to use the new API, I can confirm calls go to 0 before deleting the old endpoint.
For checking that a table or column is being accessed before changing / deleting it? Fuck, I don't actually know how I'd orchestrate that. And once I've made that change (vs when I make an API change), well, I hope I got it 100% correct because reverting that change is harder.
Of course in a narrow case where all apps that need the same DB need to be upgraded/fixed in lockstep, maybe you can get away by directly updating the database. But more than 2 teams, it will quickly be a nightmare of conflicting priorities across teams, amount deployment coordination required.
"Oh you cannot change this schema right now because 3 other apps depend on it and they dont have time to make the necessary changes in their app to accommodate this right now, for the next 6 months"
When your apps connect to a DB schema, the change is silent. You just run ALTER TABLE and… whoops, you just brought down a service you didn’t know existed because the contract was implicit.
Jeff Bezos famously said[1] that anyone who does otherwise should be fired, and I agree.
But this is only valid when you're trying to build AWS. Not everyone does that.
Relational databases have extensive permission systems for a reason.
Yeah, and databases expose extensive APIs with extremely battle-tested security and permissions models for multiple consumers.
It's important to manage your schema in code for various reasons from change control to standing up development databases, etc.
That code might in turn have plugins or feature flags that mean you don't know the concrete sql schema until runtime.
Same for seed data and migrations.
So it depends on the use-case how useful this format is for tooling and discovery vs an actual connection to the database.
If you are using an ORM, using the same language and mental model to describe your database structure as you do to interact with the database makes a lot of sense.
Often times, the indexes will reflect this. Often times, not.
Any tab called be pulled into its own window and moved to a different screen.
Even the terminal panel can be popped out into a tab or panel or window. (The UI is not obvious but once you see it you can’t unsee it)
It’s pretty cool to have the code and terminal side by side in the editor window. (Of course this was always possible with emacs)
Last time I tried to use it in my environment, it triggered too many 'external network requests' for the liking of our IT guy. We relegated it to the "Do Not Use" pile as a result.
Has this been resolved? Nobody in my team wants to use an IDE that sends data back to its masters ..
If this is “PGAdmin, but 50% worse, but it just lives as another tab in your editor instead of another application” that is genuinely a huge win for me
Probably that’s because my day-to-day isn’t actually database administration, it’s application development where I need to be able to work with a database from time to time — so the preservation of context, however marginal, is really nice.
It also recognizes your regular programming code strings as SQL and can also autocomplete/highlight typos, but I don't use that, because we're using JOOQ that generates code stubs from live DB.
New query could still get results.
Overall, it should have been a separate app because you can't really see all the results in a small panel.
The team is very receptive to feedback, in my experience.
I imagine later LLM have access to my table metadata and then perhaps down the road, LLM can suggest me better queries based on execution plans that it saw.
am I the only one to have that problem?
I really wonder why they would call it "server name" instead of database host though
Does anyone here feel that the graphical editors actually save them time or make their lives easier?
In my opinion, i see that graphical editors are more product for major section of devs and admins.
But with DataGrip I could just pull the row I was interested and paste in the string from the UI.
Surely there's another workaround that wouldn't involve a UI but this made it pretty easy.
Like, you can make websites graphically with DreamWeaver (or something), but I think most people say that you're better off using HTML and CSS and whatnot if you know how to use that.
Is this GUI stuff something people who are good at SQL actually use or is this mostly for new people?
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.
You put too many bezier curves on a page on my eyes go cross. They don't even bother to make the lines different colors. Just a bunch of white curves against a fixed grid layout. Wut?
It's taking well structured data and then destructuring it into an inaccurate sloppy picture. I don't get it.
You could argue that "events" are primary in which case just switch the order of that and "speakers."
I'd color the table headers differently and different from each other and have the arrows leaving that box match the color of the box it's leaving. Also drop "public:". It's expected and default so it does not need to be displayed here.
Drop the key icon and just make the key fields in bold or with a different style.
Don't make me hunt around to match information and don't be afraid to use differential styling.
[0] affectionately Crashional Rose
When you generate visualization, you should only show key table and key fields within the table and hide all the helper, secondary fields and tables.
In an LLM world this should be easy for LLMs to pick out key tables and fields and only display those
LLM here would be like another person or another team, that decides what's important for me, what I should see and what I should not. Might work, but I'd rather see the full picture and decide myself.
slowly development tools are catching up with the 90s
People have to stop pretending there were no IDEs before IntelliJ .
If love for there to me a "rename variable" feature.
I got my hopes up for nothing
But I prefer to keep that info with the db connection, and have it automatically run when I connect
It's a pretty standard expectation (Navicat, DBeaver, etc)
I don't understand why the first four points under this heading are basically the same.
Here's the talk where I used it: https://www.youtube.com/watch?v=k6Vm2hakkV4
I also did a theater session at our MSFT booth, but the recording isn't up yet. You can follow the steps in this repo to check out all the features that I demo'd, however: https://github.com/Azure-Samples/postgresql-extension-playgr...
Let the team know about any issues here: https://github.com/microsoft/vscode-pgsql/issues
How do I install this on Neovim then? Is there a LSP? Or is this Microsoft proprietary? I wonder how much better without Copilot integration this is then the competition.
I'm using DBeaver CE currently. Does all I need (also for SQLite).
Once you start reading press releases with this business-dictionary, it gets a lot easier to just close the tab and move on.
It’s going to be tough to beat SQLTools for Sublime Text (https://code.mteixeira.dev/SublimeText-SQLTools/). It’s simple, fast, does the basics right, and crucially, works for many of the usual suspects.
Most IDEs try to do everything and fail, yet only target one db vendor. They’re _all_ bloated and buggy, with endless trees and menus, bells and whistles. Results grids are slow, copy/paste is janky, formatting is never quite right—or outright misleading.
SQLTools stays out of the way and just works.
...also, I don’t want AI-powered nonsense. I’ll reach for that when I need it. Get off my lawn.
This is also what's said here by one of the devs: https://github.com/microsoft/vscode-pgsql/issues/15
Looks like manually loading the VSIX to bypass the compatibility check should work but who knows how stable that'll be.
wiseowise•1mo ago
someothherguyy•1mo ago
formerly_proven•1mo ago
ParetoOptimal•1mo ago