Postgres IDE in VS Code

It often is, but the schema might be written against a language-specific ORM.

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.

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.

I'm more confused why the version control of the thing using the database is including the entire schema of the database in it's repository

That "works" for about as long as you have <10 employees and <3 customers or so. After that the railsapp doesn't get to be the sole owner of the db.

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.

Out of interest.. does the resultant data get used by the LLM or just generating SQL, executing and returning separately?

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.

Here’s the link to our open roadmap—would love to hear your thoughts: https://aka.ms/vscode-mssql-roadmap

Since most databases expose similar schema views it shouldn't be too complicated. Feels like JetBrains has been doing this for a long time

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.

Thank you so much, Pamela! You’ve been an amazing and key partner in our journey—your feedback and support have truly made a difference.

are we gonna get for sqlite ?

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.

If you’re interested, here’s our open roadmap: https://aka.ms/vscode-mssql-roadmap

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.

But it's only for Windows

[dead]

There are several sqlite vs code extensions and this one's my favorite: https://marketplace.visualstudio.com/items?itemName=yy0931.v...

I can think of several improvements for Transact-SQL, starting with stored procedure packages.

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.

And most of us are invested in MSFT, so we benefit that way as well. (I don't hold any positions)

i feel like we need a first-era unsuck it search engine for this :D

Are there any features in datagrip in particular that you like that aren't in dbeaver?

I'd love to try datagrip, what are some advantages over pgadmin or others?

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.

All true.

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 didn't know about DataGrip. Looks cool.

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.

The heavy Mac UX compliance is the reason why I enjoy using Postico for 99% of straightforward Postgres tasks

Thanks, I need to move that website to GitHub Pages soon, the current host isn't handling the naked domain well. Changed to www.pamelafox.org for now.

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.

I only use Rider because it's cross-platform. It's not inherently better (or worse) than Visual Studio with Resharper installed.

Most .Net devs I know use VS, I used Rider because it’s so much less awful.

How is VSCode a "gateway drug" into the MS ecosystem? It's good PR, for sure, but it has little to no conceptual/GUI overlap with, say, Windows.

FWIW I use it via Linux .deb and integrate with a private GitLab.

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.

It is also the best Web IDE, for the return of timesharing development, sorry cloud.

Also the best webdev IDE.

Erich Gamma

VS could do web okay 5 years ago, haven't run it since.

That's ironic since I develop most of my Microsoft related tech with JetBrains products and only use vs code for frontend/node - non Microsoft stuff.

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.

Yeah I’ve been using it since it was released and can’t ever remember it being marketed as such.

I'm just picking Access as an example of an old MS "database GUI".