This solves a major problem that I built an npm package called "pgstrap"[1] for. It generates a "database structure" directory so that my database schema is available to LLMs (it also makes code review easier because you can see the changes to various tables). So I have a SQL file for each table in my database, neatly organized into directories for each schema. Rails has a similar idea with schema.rb
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 confused. Isn’t including the canonical state of the database schema in version control along with all the migrations that brought it to that point a completely standard part of every web framework?
The _canonical_ state is what is in the production database(s). What's in version control is hopefully able to recreate it, with the obvious caveat of being highly unlikely to be able to repopulate the data.
That seems like a really pragmatic tool, thanks for sharing it!
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.
Yep! It basically runs pg_dump and categorizes all of the output into different files so it should be comprehensive. I think there's `functions/function_name.sql`, `misc.sql`, `triggers.sql` etc.
Which is strictly worse than just giving the LLM access to the source of truth for the database.
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.
There is already a Microsoft SQL server extension for VS Code and this looks to effectively be a clone of it. After giving this a quick spin, it looks and feels the same as the SQL server extension, with the same menus, dialogs, etc. The SQL server extension I believe is what formed the basis of the now-deprecated Azure Data Studio (which was a VS code fork).
That’s correct—I’m the lead PM for the SQL extension in Visual Studio Code. We’ve been working closely with the PostgreSQL team; in fact, their extension is essentially a fork of ours, as you pointed out correctly.
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.
I'm a developer advocate at Microsoft, and from my perspective, both teams have been putting in a bunch of effort improving their extensions. I participated in usability studies with both the teams behind the SQL Server extension and new PostgreSQL extension, and then once they were ready, I participated in bug bashes.
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.
The problem customers have with these Shiny New Things that Microsoft keeps trying get us to switch to is that they drop features and entire product suites on the floor, even those that aren't officially deprecated and have no equivalent replacements. It's common to see SSRS, SSIS, SSAS in multidimensional mode, etc... simply forgotten about like they no longer exist.
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.
I speculate that it's because the MSSQL tools have been maintained as part of Azure Data Studio, and were in better shape.
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.
You’re right—the old PostgreSQL extension was outdated. The team recently forked our modern MSSQL extension (I’m the Lead PM) to build a new one for PostgreSQL. It’s a fresh start, built on the same foundation we’re actively improving.
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.
They built the postgres plugin in a way that nobody could usefully contribute to unless they worked at msft - like the rest of ADS the level of control they tried to maintain meant nobody wanted to work on it.
No, it has a different purpose; VS Code extension and the former ADS are targeted for development, while SSMS is for server and database administration. I am a heavy user of SSMS and can do everything I ever need there, I don't use the VS Code extension for MS SQL even if I have it installed and I use VS Code quite a lot. This is because I am also acting as a backup and supervisor for our DBA team, so I am involved in DBA work.
The copilot integrations look sweet, as does the schema view. The MSSQL extension doesn't have those, but the rest of it looks similar to the Postgres one.
Lead PM for MSSQL extension in VS Code here. I’m glad to share that we have both features (Schema Designer, GitHub Copilot) into the MSSQL extension for VS Code. You can check out this end-to-end demo showcasing those capabilities: https://aka.ms/vscode-mssql-copilot-demo
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.
> going all in on open source over the past 10-15 years.
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.
Also, given that they recently bought github, they have financial incentive to keep people there, who might upgrade to pro accounts or grow to need enterprise.
MS SQL server is a legacy system. I don't think any business would create a new database using SQL server unless, for some technical reason, they don't have any other option.
Azure SQL Database for a long while has been the most cost-effective way of running SQL Server as a PaaS database, and still is if you choose the DTU-based modes, making it a very attractive option. Combined with the rich feature set and maturity and reliability of SQL Server, it is hardly legacy; in fact it's very capable and continues to get new updates like vector operations.
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.
There is a parallel world, called enterprise. The enterprise people in this world, like enterprise software.
They were born to be enterprise oriented. This is fine. Not everyone is like you and it's ok to use a robust product like MSSQL.
>> all without ever leaving your favorite code editor
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).
When for-profit companies write "Democratizes X for all" it means "for people who can pay and aren't embargoed". When they write "Simplify" it means "Get locked in to our ecosystem". When they write "Your favorite X" it means "The product we're selling to you", and so on.
Once you start reading press releases with this business-dictionary, it gets a lot easier to just close the tab and move on.
Even for DuckDB, I use DBeaver CE the last 9 years professionally. Also when I do Python Dev I reach for JupySQL in Jupyter when I need something quick and it works in VSCode through Jupyter plugin..
will definitely be taking a look at this. i started my career on mostly SQL Server and using SSMS fits my brain like a glove. i've been so dissatisfied with the typical options (pgadmin, dbeaver, datagrip, etc) for managing/querying postgres since i started using it probably like 10 years ago. postgres itself is great (don't get it twisted either, SQL Server is fantastic. just costs money) but i never understood why there wasn't more uproar in the community about its DBMS tooling ecosystem
I've found Datagrip to be far and away the most impressive universal database tool. I feel like I've tried them all, and they all have a quality of having been developed by database people, rather than IDE designers. The depth of capability, extensibility, pace of improvement--I'm a very happy customer.
I don't want to poop on open source, but pgadmin and dbeaver and not even close to playing in the same league.
In my experience most SQL developers don't care too much about tooling. In most cases someone designs the database and tables, developers don't care about databases and care mostly about tables and views, rarely about indexes. The ones that care, and need tooling, are usually called development DBAs and they are very rare. Rare enough I was never able to hire one and keep them (we don't pay enough for how rare they are).
I've been in that camp for much of my career, and yes, tooling matters.
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.
Hmmm, interesting. I used Datagrip for some years, now DBeaver (as I don't have a JB subscription anymore). Datagrip was and probably still is very powerful with top intellisense. Now I'm using DBeaver and it's very solid. Ok, I'm not spending my whole day in it, but when I need it, it does the job well.
I think Code has fine git integration, but they way they implement it is just very Microsoft. The UI is very much like the one they use in their professional Visual Studio UI, and whether that's a good thing or not is definitely a very personal choice.
I much prefer JB's git integration, but I wouldn't discount it just because the UI is so completely different.
I wonder what is the most "valuable" IDE right now for MS. A few years ago VsCode was marketed essentially as "Visual studio for beginners", where you were supposed to move to Visual Studio after you became a real dev, but since then VSCode has been growing and growing and stands now as the most used "IDE", where Visual Studio is mostly seen as "legacy" (oversimplification, great IDE for CPP and .NET but still...).
Easily VSCode, if we're talking about developer reach. I'm not big into Microsoft stuff, but almost every 'serious' .Net developer I personally know is using Rider, so I can only assume that Visual Studio is retreating to the same space occupied by Eclipse and Netbeans, i.e. still used, but mostly only in places where change is hard.
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.
I work at a mostly .NET firm and almost all the developers on that side of things are on Visual Studio. Rider has less penetration than PyCharm has among the Python devs.
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.
VS Code is a downgrade from open source to freeware. At least the C++ plugin is freeware. And they block access to the extension store from any fork (self-compiling VS code is also considered a fork).
So if you are an OSS purist, VS is bad. Other than that it's effing great.
> where you were supposed to move to Visual Studio after you became a real dev
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.
it has to be VS Code by a long shot. They don't charge for it, but it serves as an enormous draw to keep people in the MS ecosphere and keeps MS in the developer game.
> A few years ago VsCode was marketed essentially as "Visual studio for beginners", where you were supposed to move to Visual Studio after you became a real dev,
I wont likely find the video but I remember watching the PM for both VSCode and VS (at the time was the same one, not sure now) recommending people to move to Visual Studio "eventually". I clearly remember it because it didn't make any sense, even if the names were similar there were/are nothing alike UI-wise and supported-language-wise. I said few years ago but it was prob around 8 years ago, vsc was still pretty young.
Readit News
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"
[1] https://github.com/seveibar/pgstrap
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.
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.
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.
Deleted Comment
Quite amazing they put the effort into this for Postgres instead of SQL Server. The demand must be a lot higher.
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
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.
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...
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...
Dead Comment
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.
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.
Deleted Comment
Embrace, extend, extinguish.
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.
But they charge you an arm and a leg for the pleasure, but it can be worthwhile for enterprise.
The reason people don't use them more often is that they're not free or even inexpensive.
that's every SQL server out there included Postgres. Is NoSQL considered as none-legacy?
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.
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.
Deleted Comment
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.
I much prefer JB's git integration, but I wouldn't discount it just because the UI is so completely different.
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
Deleted Comment
Dead Comment
Deleted Comment
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.
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.
Also the best webdev IDE.
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.
It is becoming common for some to use Rider primarily, but VS is still used as part of the build system.
When was that?