Great question! Postgres is supported right away because it behaves like a standard, direct database connection. But with services like Neon and Supabase, there are extra nuances we want to handle properly.
We want Neon, Supabase, and similar cloud providers to feel like first-class citizens inside DB Pro and not just “another Postgres connection”. Each of them has their own quirks, authentication flows, and connection requirements. For example, Supabase actually needs a paid IPv4 add-on if you want to connect to it in the traditional way, which isn’t obvious to most users.
So instead of lumping them in as generic Postgres connections, we’re building dedicated flows that understand these details and make the whole experience seamless. That’s why they’re marked as “coming soon”. We’re doing them properly.
It all goes back to our UX first philosophy to build the absolute best experience.
Are we at the point where I can store arbitrary scripts in a sql database and execute them with arguments, safely in a python sandbox from a host language that may or may not be python, and return the value(s) to the caller?
I'd love to implement customer supplied transformation scripts for exports of data but I need this python to be fully sandboxed and only operate on the data I give it.
Wasmer's approach hints at faster cold starts and better overall performance; the benchmarking against pyodide is a bit unclear, and it's unclear to me whether that would make or break viability for a use case like this.
But one thing this does make possible is if your arbitrary script is actually a persistent server, you can deploy that to edge servers, and interact with your arbitrary scripts over the network in a safe and sandboxed way!
That's almost exactly what I want to do too. I've experimented a bit with QuickJS for this - there's a Python module here that looks reasonably robust https://pypi.org/project/quickjs/ - but my ideal would be a WebAssembly sandbox since that's the world's most widely tested sandbox at this point.
I wish python had proper sandbox configuration. This would be great for user defined scripts but only if I could disable filesystem and network syscalls for the user defined code.
This uses UDS (Unix Domain Sockets) to communicate, which are file-like and can be mounted from the host filesystem inside a container.
As long as the socket is writable, the rest of the filesystem(s) don't have to be. Same goes for the networking, which can be very isolated and restricted.
One day Claude will do it correctly but today is not that day.