Both will either download or ship the postgres binary with your app, and run it in a separate process. Pglite is different, it's actually a library (they have stripped some parts of the postgres source code) and it could in principle be ported to be used as a native library (meaning, you link to it and run as a single program)
There's even a draft PR to do this, but it became stale
Yes, what you get is a multi-server postgres under the covers. But for many users, the convenience of "uv pip install...", auto clean up via context manager is the higher order bit that takes them to SQLite.
Of course the bundled extensions are the key differentiator.
With enough distribution and market opportunities we (yes, there is a for profit company behind it) can invest in making it truly embedded.
frick this gotta be the tenth time ive read about pglite here and i always go look for native library. shame pr became stale, webapps simply arent always my end game. thanks for putting pglite-oxide on my radar tho, this is an interesting almost-there i can tinker with.
Python has a performance problem. Most people may not need it, but many people do. Languages like Rust and Go are heavily adopted by Python programmers either trying to understand low-level concepts or looking for something more performant.
And this is before we talk about the real selling point, which is enabling portable heterogenous compute.
py2many can compile static python to mojo, apart from rust and golang.
Is it comprehensive? No. But it's deterministic. In the age of LLMs, with sufficient GPU you can either:
* Get the LLM to enhance the transpiler to cover more of the language/stdlib
* Accept the non-determinism for the hard cases
The way mojo solves it is by stuffing two languages into one. There are two ways to write a function for example.
I don't think the cost imposed by a transpiler is worse. In fact, it gets better over time. As the transpiler improves, you stop thinking about the generated code.
Thank you for the shout out! I looked into your benchmark setup a bit. Two things going on:
- Ladybug by default allocates 80% of the physical memory to the buffer pool. You can limit it. This wasn't the main reason.
- Much of the RSS is in ladybug native memory connected to the python connection object. I noticed that you keep the connection open between benchmark runs. For whatever reason, python is not able to garbage collect the memory.
We ran into similar lifetime issues with golang and nodejs bindings as well. Many race conditions where the garbage collector releases memory while another thread still has a reference to native memory. We now require that the connection be closed for the memory to be released.
I am actually only vaguely familiar and I was wondering about that every time I saw the format referenced but never bothered to check, your comment is informative!
Yeah, I'm a long time user/disciple of https://zim-wiki.org ; it was basically Obsidian but 15-20 years early. To do some of the things that are now trivially easy with Obsidian I learned scripting and such, so I'm familiar with this very weird coincidence/name collision.
I really curious about what the world of archival formats is like - is there consensus? are the most-used formats actually any good and well-supported,and self documenting?
reply