HN user
Co-founder at JourneyApps, currently focusing on PowerSync.
https://powersync.com
Why would anyone use GridFS for any serious use case? It costs 10-20x as much as storing the files on S3. If unless you already have all your data in MongoDB and don't want an additional dependency for a small number of files it makes sense, but it definitely is not a case for using MongoDB by itself.
LLMs do learn from mistakes. Not as directly from individual mistakes like humans do, but in aggregate the models have improved much more in the last year than most humans I know learn in the same time.
Do you mean "Unlike Deno Desktop"? Deno Desktop definitely relies on a browser engine.
Yeah, they don't make it that clear, but you get basically the same functionality as with LetsEncrypt for free, including wildcard certs. You basically only need to pay for manually issued certs, or some of their other additional features.
I use them in some cases to avoid the rate limits on LetsEncrypt, and they have better support for some older platforms (like ancient Android versions), and I'm pretty happy so far. I have a paid account to support them, but it's not a requirement for ACME certs. It works without issue with Kubernetes Certbot, and seamless to switch between ZeroSSL and LetsEncrypt.
I can't comment on the EU part though - not that relevant in my case.
At PowerSync we use a wa-sqlite build with SQLite3MultipleCiphers for encryption at rest.
You do still need a secure key to use with this. The simplest is to persist the key server-side (and specifically not on the client), and provide it to the JS after signing in. If you need to support a completely offline PWA you need something else, e.g. prompting the user for a passcode each load.
Now you can ask "Is it easier to ask an AI agent to do X than asking my employee?"
Good metrics is difficult, but sometimes a simple comparison like that is enough.
Yup - interesting to see so much written about Postgres having a performance regression on Linux 7.0, in a scenario that affects almost no-one in practice. Meanwhile MongoDB refuses to run at all on Linux 7.0 due to some issue with tcmalloc.
In many of my projects don't show any closed pull requests for the last 6 days. The CLI can list them, but anything going through search shows nothing.
Their support acknowledged the issue, but has been silent since then, and the status page still shows nothing other than the potentially-related issue on the 27th. It looks like it has been resolved on some repositories in the meantime, but I still have the issue across multiple orgs and repositories.
This is not just about the UI, it's about the mental model and management of the changes.
Just covering the review process:
Yes, you can structure your PR into 3 commits to be reviewed separately. I occasionally structure my PRs like this - it does help in some cases. But if those separate parts are large, you really want more structure around it than just a commit.
For example, let's say you have parts A, B and C, with B depending on A, and C depending on B.
1. I may want to open a PR for A while still working on B. Someone may review A soon, in which case I can merge immediately. Or perhaps it will only be reviewed after I finished C, in which case I'll use a stacked PR. 2. The PR(s) may need follow up changes after initial review. By using stacked PRs instead of just separate commits, I can add more commits to the individual PRs. That makes it clear what parts those commits are relevant to, and makes it easy to re-review the individual parts with updated changes. Separate commits don't give you that.
Stacked PRs is not a workflow I'd use often, but there are cases where it's a valuable tool.
Then apart from the review process, there are lots of advantages to keeping changes small. Typically, the larger a change, the longer it lives in a separate branch. That gives more time for merge conflicts to build up. That gives more time for underlying assumptions to change. That makes it more difficult to keep a mental map of all the changes that will be merged.
There are also advantages to deploying small changes at a time, that I won't go into here. But the parent's process of potentially merging and deploying the search index first makes a lot of sense. The extra overhead of managing the index while it's "unused" for a couple of days is not going to hurt you. It allows early testing of the index maintenance in production, seeing the performance overhead and other effects. If there's an issue, it's easy to revert without affecting users.
The overall point is that as features become large, the entire lifecycle becomes easier to manage if you can split it into smaller parts. Sometimes the smaller parts may be user-visible, sometimes not. For features developed in a day or two, there's no need to split it further. But if it will span multiple weeks, in a project with many other developers working on, then splitting into smaller changes helps a lot.
Stacked PRs is not some magical solution here, but it is one tool that helps manage this.
I can see a lot of time was put into the report, and it helps to have the detail, but in my mind it glosses over one of the most important parts: The dispute in the stewardship of the bundler and rubygems open-source projects.
As I understand it, Ruby Central controlled the rubygems and bundler github organizations, but did not "own" the projects in the traditional sense - the individual contributers have copyright on the code, and potentially even trademark rights. By then removing access of core maintainers to those projects, they removed access to something they don't "own" themselves.
This is all complicated by the fact that controlling a github organization or repo is different from owning the trademark or copyright. But some of the original maintainers clearly felt they had more of a right to those projects than Ruby Central did.
I believe not clarifying this before making these access changes was the biggest mistake that Ruby Central made, and it's not even mentioned in this report.
What features are you using that the $18/user/month plan doesn't cover?
In my experience, Windows is very far from a "it just works" OS.
This is still an interesting read, but has anything here changed in the meantime? And out of interest, do other JS engines use the same type of structure to represent properties?
There are a bunch of utilities that don't actually _do_ anything useful. The proxy in this example is used for nothing other than debug logs. The DOM utility layer just slightly reduces the number of LOC to create a DOM node.
And then you end up with consumer code that is not actually declarative? The final code still directly manipulates the DOM. And this shows the simplest possible example - creating and removing nodes. The difficult part that libraries/frameworks solve is _updating_ the DOM at scale.
If that is your source, then Safari was _way_ behind for all of 2025 up until this month, where it suddenly caught up.
Superset of dependencies, but often a subset of info per depedency.
SBOM may contain similar info to lockfiles, but the purposes are entirely different.
Lockfiles tells the package manager what to install. SBOM tells the user what your _built_ project contains. In some cases it could be the same, but in most cases it's not.
It's more complicated than just annotating which dependencies are development versus production dependencies. You may be installing dependencies, but not actually use them in the build (for example optional transitive dependencies). Some build tools can detect this and omit them from the SBOM, but you can't omit these from your lockfile.
Fundamentally, lockfiles are an input to your developement setup process, while SBOM is an output of the build process.
Now, there is still an argument that you can use the same _format_ for both. But there are no significant advantages to that: The SBOM is more verbose, does not diff will, will result in worse performance.
As mentioned in those threads, there is no SQLite WAL corruption if you have a working disk & file system. If you don't, then all bets are off - SQLite doesn't protect you against that, and most other databases won't either. And nested transactions (SAVEPOINT) won't have have any impact on this - all it does in this form is reduce the number of transactions you have.
We're relying on logical replication heavily for PowerSync, and I've found it is a great tool, but it is also very low-level and under-documented. This article gives a great overview - I wish I had this when we started with our implementation.
Some examples of difficulties we've ran into: 1. LSNs for transactions (commits) are strictly increasing, but not for individual operations across transactions. You may not pick this up during basic testing, but it starts showing up when you have concurrent transactions. 2. You cannot resume logical replication in the middle of a transaction (you have to restart the transaction), which becomes relevant when you have large transactions. 3. In most cases, replication slots cannot be preserved when upgrading Postgres major versions. 4. When you have multiple Postgres clusters in a HA setup, you _can_ use logical replication, but it becomes more tricky (better in recent Postgres versions, but you're still responsible for making sure the slots are synced). 5. Replication slots can break in many different ways, and there's no good way to know all the possible failure modes until you've run into them. Especially fun when your server ran out of disk space at some point. It's a little better with Postgres 17+ exposing wal_status and invalidation_reason on pg_replication_slots. 6. You need to make sure to acknowledge keepalive messages and not only data messages, otherwise the WAL can keep growing indefinitely when you don't have incoming changes (depending on the hosting provider). 7. Common drivers often either don't implement the replication protocol at all, or attempt to abstract away low-level details that you actually need. Here it's great that the article actually explains the low-level protocol details.
Probably a security feature. If it can access the internet, it can send your private data to the internet. Of course, if you allow it to run arbitrary commands it can do the same.
FoundationDB also has a Mongo-compatible document layer, but it seems like the last release was 6 years ago, so probably doesn't count anymore.
The project looks great! Object storage is often so much better in terms of cost efficiency than a database on EBS. It's often 10-20x more expensive for EBS after taking into account that you need 3x replicas for a typical MongoDB deployment, and need to over-provision the storage. And being able to scale compute independently from storage is great.
The biggest things I'm missing from the docs (checked the github page and the site) is seeing what MongoDB features are supported or not. I've worked with Azure CosmosDB before, and even though it claims MongoDB compatibility, it has many compatibility issues as soon as you have more than a basic CRUD application. Some examples include proper ChangeStream support, partial index support, multi-key index support, set of supported aggregation pipeline operations, tailable cursor support, snapshot queries.
Another thing that's not clear: What does multi-master/multi-write mean in practice? What happens if you write to the same data at the same time on different nodes?
That is completely wrong for this stage of a company. The ability to make profit in the future is important. Making profit while growing is not.
Let's say I have an open-source project licensed under Apache 2. The grant allows me to include the extension in my project. But it doesn't allow me to relicense it under Apache 2 or any other compatible license. So if I include it, my project can't be Apache 2-licensed anymore.
Apache 2 is just an example here - the same would apply for practically any open source license.
The one place I imagine it could still work is if the open-source project, say a sqlite browser, includes it as an optional plugin. So the project itself stays open-source, but the grant allows using the proprietary plugin with it.
It would help to have more info on what you need to run this. The page mentions "without the need for any new hardware", but doesn't say what existing types of hardware it is compatible with. The apps available for download gives a hint, but are the apps for displaying the content, or for controlling the content?
For example, I recently setup a dashboard using a Raspberry Pi running Chromium - would this work for my use case?
And does the control work over the local network, or does it require an internet connection?
Overall, I haven’t seen many issues with the drives, and when I did, it was a Linux kernel issue.
Reading the linked post, it's not a Linux kernel issue. Rather, the Linux kernel was forced to disable queued TRIM and maybe even NCQ for these drives, due to issues in the drives.
There may be good reasons to do that, but this isn't one. Any project using CocoaPods will still remain working for the foreseeable future - you'll just not get new updates to dependencies at some point. And at that point you can migrate to SwiftPM or vendored dependencies, without losing anything.
You'll still be able to use those - the CocoaPods repo will not go away any time soon. If someone wants to provide updates for those, it has to be migrated to SwiftPM. And in the meantime you may have to use both SwiftPM and CocoaPods, or fork & migrate those yourself.
wa-sqlite on top of OPFS is actually pretty great these days. Performance is about half of what I'd get in native SQLite, which is not too bad overall. It's around 10x faster than SQLite on top of IndexedDB for large databases in my experience.
It's much better than WebSQL could ever be. You get the full power of modern SQLite, with the version, compile options, additional extensions, all under your control.