[deepakprakash]

Can someone explain a bit more?

(a) Does this mean that there will be an sqlite version that can be deployed as a process accessible over network in servers?

(b) Does this mean that sqlite will now have the capability to do concurrent reads/writes, but that it is upto users to implement a process that can take advantage of this and create something like (a)?

[X-Istence]

> (a) Does this mean that there will be an sqlite version that can be deployed as a process accessible over network in servers?

No.

> (b) Does this mean that sqlite will now have the capability to do concurrent reads/writes, but that it is upto users to implement a process that can take advantage of this and create something like (a)?

Yes... this allows a multi-threaded application for example to have multiple readers/writers without blocking each other.

[nbevans]

... as long as those threads don't touch the same page as each other. Page locks <> row locks.

[blattimwind]

Depends on the width of your rows and the relation of access patterns to physical row allocation.

[hd4]

For some reason, I had the idea that this was always the case with SQLite, at least for the last 10 years or so.

[blattimwind]

In WAL mode, readers don't block writers and vice versa, but there can still only be one writer active at any given time.

[dragonwriter]

This provides (b), not (a).