I opened a TPC-H SF1GB database with GizmoSQL, started 3 concurrent client sessions, and had each session run:
BEGIN TRANSACTION; INSERT INTO lineitem SELECT * FROM lineitem; COMMIT;
None of the 3 sessions were blocked - and all were able to insert into the table, and read the results of their inserts before committing.
It was very cool to see also that writes do NOT block reads from other sessions - the other sessions just could not see uncommitted data.
After committing in one session, the other sessions could see the data that was inserted.
I haven't stress tested the system to get limits, but I thought this little test would prove useful information for your question.
I'll work to do some benchmarking on concurrent inserts, etc.
Updates to the same data by multiple sessions behave a little differently - see details from page: https://duckdb.org/docs/stable/connect/concurrency.html
Thanks for your question!
I opened a TPC-H SF1GB database with GizmoSQL, started 3 concurrent client sessions, and had each session run:
BEGIN TRANSACTION; INSERT INTO lineitem SELECT * FROM lineitem; COMMIT;
None of the 3 sessions were blocked - and all were able to insert into the table, and read the results of their inserts before committing.
It was very cool to see also that writes do NOT block reads from other sessions - the other sessions just could not see uncommitted data.
After committing in one session, the other sessions could see the data that was inserted.
I haven't stress tested the system to get limits, but I thought this little test would prove useful information for your question.
I'll work to do some benchmarking on concurrent inserts, etc.
Updates to the same data by multiple sessions behave a little differently - see details from page: https://duckdb.org/docs/stable/connect/concurrency.html
Thanks for your question!