Does this help with DuckDB concurrency? My main gripe with DuckDB is that you can't write to it from multiple processes at the same time. If you open the database in write mode with one process, you cannot modify it at all from another process without the first process completely releasing it. In fact, you cannot even read from it from another process in this scenario.
So if you typically use a file-backed DuckDB database in one process and want to quickly modify something in that database using the DuckDB CLI (like you might connect SequelPro or DBeaver to make changes to a DB while your main application is 'using' it), then it complains that it's locked by another process and doesn't let you connect to it at all.
This is unlike SQLite, which supports and handles this in a thread-safe manner out of the box. I know it's DuckDB's explicit design decision[0], but it would be amazing if DuckDB could behave more like SQLite when it comes to this sort of thing. DuckDB has incredible quality-of-life improvements with many extra types and functions supported, not to mention all the SQL dialect enhancements allowing you to type much more concise SQL (they call it "Friendly SQL"), which executes super efficiently too.
Hi, DuckDB DevRel here. To have concurrent read-write access to a database, you can use our DuckLake lakehouse format and coordinate concurrent access through a shared Postgres catalog. We released v1.0 yesterday: https://ducklake.select/2026/04/13/ducklake-10/
I updated your reference [0] with this information.
Regarding documentation, I think the DuckLake docs would benefit from a relatively simple “When should I consider using DuckLake?” type FAQ entry. You have sections for what, how, and why, essentially, and a few simple use cases and/or case studies could help provide the aha moment to people in data jobs who are inundated with marketing from other companies. It would help folks like me understand under which circumstances I would stand to benefit most from using DuckLake.
DuckDB devrel here. You are right. This was in the FAQ but I also added it to the DuckLake documentation's main page at https://ducklake.select/docs/stable/
DuckLake is great for the lakehouse layer and it's what we use in production. But there's a gap and thats what I'm trying to address with OpenDuck. DuckLake do solve concurrent access at the lakehouse/catalog level and table management.
But the moment you need to fall back to DuckDB's own compute for things DuckLake doesn't support yet, you're back to a single .duckdb file with exclusive locking. One process writes, nobody else reads.
OpenDuck sits at a different layer. It intercepts DuckDB's file I/O and replaces it with a differential storage engine which is append-only layers with snapshot isolation.
Yes, this is actually one of the core problems OpenDuck's architecture addresses.
The short version: OpenDuck interposes a differential storage layer between DuckDB and the underlying file. DuckDB still sees a normal file (via FUSE on Linux or an in-process FileSystem on any platform), but underneath, writes go to append-only layers and reads are resolved by overlaying those layers newest-first. Sealing a layer creates an immutable snapshot.
This gives you:
Many concurrent readers: each reader opens a snapshot, which is a frozen, consistent view of the database. They don't touch the writer's active layer at all. No locks contended.
One serialized write path: multiple clients can submit writes, but they're ordered through a single gateway/primary rather than racing on the same file. This is intentional: DuckDB's storage engine was never designed for multi-process byte-level writes, and pretending otherwise leads to corruption. Instead, OpenDuck serializes mutations at a higher level and gives you safe concurrency via snapshots.
So for your specific scenario — one process writing while you want to quickly inspect or query the DB from the CLI — you'd be able to open a read-only snapshot mount (or attach with ?snapshot=<uuid>) from a second process and query freely. The writer keeps going, new snapshots appear as checkpoints seal, and readers can pick up the latest snapshot whenever they're ready.
It's not unconstrained multi-writer OLTP (that's an explicit non-goal), but it does solve the "I literally cannot even read the database while another process has it open" problem that makes DuckDB painful in practice.
Nice app! I see that the page title says "client" and there's the Vite favicon still, which you might want to fix :)
I also think having a dropdown for the address search is somewhat expected these days, but is lacking here. That might be on purpose or due to a technical limitation, but just thought I'd mention.
That is not correct at all. How did you arrive at that conclusion?
GPS has its own independent timescale called GPS Time. GPS Time is generated and maintained by Atomic clocks onboard the GPS satellites (cesium and rubidium).
It has its own timescale, but that still traces back to NIST.
In particular, the atomic clocks on board the GPS satellites are not sufficient to maintain a time standard because of relativistic variations and Doppler effects, both of which can be corrected, but only if the exact orbit is known to within exceeding tight tolerances. Those orbital elements are created by reference to NIST. Essentially, the satellite motions are computed using inverse GPS and then we use normal GPS based on those values.
> It has its own timescale, but that still traces back to NIST.
GPS gets its time from the US Naval Observatory:
> Former USNO director Gernot M. R. Winkler initiated the "Master clock" service that the USNO still operates,[29][30] and which provides precise time to the GPS satellite constellation run by the United States Space Force. The alternate Master Clock time service continues to operate at Schriever Space Force Base in Colorado.
> As a matter of policy, the U.S. Naval Observatory timescale, UTC(USNO), is kept within a close but unspecified tolerance of the international atomic timescale published by the Bureau International des Poids et Mesures (International Bureau of Weights and Measures [BIPM]) in Sevres, France. The world's timing centers, including USNO, submit their clock measurements to BIPM, which then uses them to compute a free-running (unsteered) mean timescale (Echelle Atomique Libre [EAL]). BIPM then applies frequency corrections ("steers") to EAL, based on measurements from primary frequency standards and intended to keep the International System's basic unit of time, the second, constant. The result of these corrections is another timescale, TAI (Temps Atomique International or International Atomic Time). The addition of leap seconds to TAI produces UTC. The world's timing centers have agreed to keep their real-time timescales closely synchronized ("coordinated") with UTC. Hence, all these atomic timescales are called Coordinated Universal Time (UTC), of which USNO's version is UTC(USNO).
The two organizations do seem to keep an eye on each other:
> The United States Naval Observatory (USNO) and the National Institute of Standards and Technology (NIST) make regular comparisons of their respective time scales. These comparisons are made using GPS common-view measurements from up to approximately 10 GPS satellites. The table below lists recent differences between the two time scales.
I think GP might’ve been referring to the part of Jeff’s post that references GPS, which I think may be a slight misunderstanding of the NIST email (saying “people using NIST + GPS for time transfer failed over to other sites” rather than “GPS failed over to another site”).
The GPS satellite clocks are steered to the US Naval Observatory’s UTC as opposed to NIST’s, and GPS fails over to the USNO’s Alternate Master Clock [0] in Colorado.
I find this stuff really interesting, so if anyone's curious, here's a few more tidbits:
GPS system time is currently 18s ahead of UTC since it doesn't take UTC's leap seconds into account [0]
This (old) paper from USNO [1] goes into more detail about how GPS time is related to USNO's realization of UTC, as well as talking a bit about how TAI is determined (in hindsight! - by collecting data from clocks around the world and then processing it).
> If those other applications use their own local GPS clocks, what is the significance of NIST (and the 5μs inaccuracy) in their scenario?
Verification and traceability is one reason: it's all very well to claim you're with-in ±x seconds, but your logs may have to say how close you are to the 'legal reality' that is the official time of NIST.
NIST may also send out time via 'private fibre' for certain purposes:
That would cause your active connections to break because the source IP changed entirely. Are you sure the IP changes abruptly, or they keep it for as long as the session is live? Though keeping the original IP would mean that, for example, if you are sailing around the world, you'd start getting worse and worse latency as all your data continues going to the original ground station which may be on the other side of the world at that point.
An interesting problem - I wonder what they truly do here. I suppose people expect interruptions with Starlink so doing an IP swap wouldn't be all that different to losing service due to obstruction for a few minutes.
IP addresses change all the time. It changes when connect to WiFi, it changes when enter new country, it changes when provider gives you new address. I cant tell if changes on mobile, it looks like mobile providers hand off to next tower, but there must be a limit of how far can go before routing breaks.
Everything retries cause there isn’t difference between new address or bad connection. Most of time we don’t notice cause not using device. Or because most connections are short lived.
I'm aware that the public IP changes when a phone (on which one hardly has much control over how things run anyway), switches from cellular to a WiFI network.
Your comments are more practical (and maybe aimed at a layman's use of Starlink) but I am talking about the theory of Starlink supposedly interrupting a perfectly-working connection in order to change your IP, which interrupts everything, by design of TCP/conntrack. Whether that operation is fatal or not due to retries or whatever else is not my point at all.
Also, ISPs at home don't randomly disconnect you to give you a new IP. They may give you a new IP when you disconnect and reconnect for other reasons, but they should never dump your connection on purpose just to give you a new IP for no reason. That's not good design at all, hence the question about how Starlink handles wanting to give you a new IP.
Serious question: If it's an improved 2.5 model, why don't they call it version 2.6? Seems annoying to have to remember if you're using the old 2.5 or the new 2.5. Kind of like when Apple released the third-gen iPad many years ago and simply called it the "new iPad" without a number.
If they're going to include the month and year as part of the version number, they should at least use big endian dates like gemini-2.5-flash-preview-2025-09 instead of 09-2025.
Or, you know, just Gemini 2.6 Flash. I don't recall the 2.5 version having a date associated with it when it came out, though maybe they are using dates now. In marketing, at least, it's always known as Gemini 2.5 Flash/Pro.
It always had dates... They release multiple versions and update regularly. Not sure if this is the first 2.5 Flash update, but pretty sure Pro had a few updates as well...
This is also the case with OpenAI and their models. Pretty standard I guess.
They don't change the versioning, because I guess they don't consider it to be "a new model trained from scratch".
If only there was some of versioning nomenclature they could use. Maybe even one that is … semantic? Oh how I wish someone would introduce something like this to the software engineering field. /s
In all seriousness though, their version system is awful.
2.5 is not the version number, it's the generation of the underlying model architecture. Think of it like the trim level on a Mazda 3 hatchback. Mazda already has the Mazda 3 Sport in their lineup, then later they release the Mazda 3 Turbo which is much faster. When they release this new version of the vehicle its not called the Mazda 4... that would be an entirely different vehicle based on a new platform and powertrain etc (if it existed). The new vehicle is just a new trim level / visual refresh of the existing Mazda 3.
That's why Google names it like this, but I agree its dumb. Semver would be easier.
I suspect Google doesn't want to have to maintain multiple sub-versions. It's easier to serve one 2x popular model than two models where there's flux between the load on each, since these things have a non-trivial time to load into GPU/TPU memory for serving.
Even if switching quickly was a challenge[1], they are using these models in their own products not just selling them in a service, the first party applications could quite easily adapt to this by switching quickly to the available model and freeing up the in-demand one.
This is the entire premise behind the cloud, the reason it was Amazon did it first, they had the largest workloads at the time before Web 2.0 and SaaS was a thing.
Only businesses with large first party apps succeeded in the cloud provider space, companies like HP, IBM all failed and their time to failure strongly correlated to their amount of first party apps they operated. i.e. These apps anyway needed to keep a lot of idle capacity for peak demand capacity they could now monetize and co-mingle in the cloud.
LLMs as a service is not any different from S3 launched 20 years ago.
---
[1] It isn't, at the scale they are operating these models it shouldn't matter at all, it is not individual GPUs or machines that make a difference in load handling at all. Only few users are going to explicitly pining a specific patch version for the rest they can serve either one that is available immediately or cheaply.
Have they fixed the ability to easily transfer your existing Android data to the new Android phone? I find that every time I upgrade, despite choosing the options to transfer apps/settings, that 90% of the apps I open just greet me with the login screen and I have to set everything up completely from scratch. I remember maybe a handful of apps, I think one was Uber, that were able to transfer everything including the login session. That was truly magic. That's how it should be for all apps. I understand banks might have special security requirements and I already know for Google Wallet, your cards need to be reactivated even if they transfer over, but most apps are not banks.
Blame the app developers, not google. They specifically added a backup/restore mode for device to device transfer, that bypasses backup blacklists[1]. However apps can still opt out by registering a backup agent, and returning no data.
Google actively avoided providing a local, secure, and seamless backup or even an interface for 3rd party backup services to make users more dependent on Google cloud services.
Of course many app developers decided the Google cloud is too insecure, being not end-to-end encrypted.
And Google enables them by not giving the users ways to override those stupid decisions. This wouldn't have happened on PCs, where you can mostly just copy over the application's user directory.
>Of course many app developers decided the Google cloud is too insecure, being not end-to-end encrypted
But so far as I can tell D2D transfers don't hit the cloud?
>For a D2D transfer, the Backup Manager Service queries your app for backup data and passes it directly to the Backup Manager Service on the new device, which loads it in to your app.
- signed url's in case you want a session base files download
- default public files, for e.g. a static site.
You can also map a domain (sub-domain) to Cloudfront with a CNAME record and serve the files via your own domain.
Cloudfront distributions are also CDN based. This way you serve files local to the users location, thus increasing the speed of your site.
For lower to mid range traffic, cloudfront with s3 is cheaper as the network cost of cloudfront is cheaper. But for large network traffic, cloudfront cost can balloon very fast. But in those scenarios S3 costs are prohibitive too!
So if you typically use a file-backed DuckDB database in one process and want to quickly modify something in that database using the DuckDB CLI (like you might connect SequelPro or DBeaver to make changes to a DB while your main application is 'using' it), then it complains that it's locked by another process and doesn't let you connect to it at all.
This is unlike SQLite, which supports and handles this in a thread-safe manner out of the box. I know it's DuckDB's explicit design decision[0], but it would be amazing if DuckDB could behave more like SQLite when it comes to this sort of thing. DuckDB has incredible quality-of-life improvements with many extra types and functions supported, not to mention all the SQL dialect enhancements allowing you to type much more concise SQL (they call it "Friendly SQL"), which executes super efficiently too.
[0] https://duckdb.org/docs/current/connect/concurrency
reply