←back to thread

SQLite async connection pool for high-performance

(github.com)
197 points slaily | 1 comments | 11 Jul 25 10:26 UTC | HN request time: 0s | source
Show context
d1l ◴[14 Jul 25 21:08 UTC] No.44565326[source]▶
This is strange on so many levels.

SQLite does not even do network I/O.

How does sharing a connection (and transaction scope) in an asyncio environment even work? Won’t you still need a connection per asyncio context?

Does sqlite_open really take long compared to the inevitable contention for the write lock you’ll see when you have many concurrent contexts?

Does sqlite_open even register in comparison with the overhead of the python interpreter?

What is an asyncio SQLite connection anyways? Isn’t it just a regular one that gets hucked into a separate thread?

replies(4): >>44565652 #>>44568010 #>>44570930 #>>44572931 #
pjmlp ◴[15 Jul 25 13:28 UTC] No.44570930[source]▶
For some strange reason, some people feel like using SQLite all over the place, even when a proper RDMS would be the right answer.
replies(2): >>44571310 #>>44571407 #
1. 9rx ◴[15 Jul 25 14:16 UTC] No.44571407[source]▶
It is not that strange when you consider the history. You see, as we started to move away from generated HTML into rich browser applications, we started to need minimal direct DBMS features to serve the rich application. At first, few functions were exposed as "REST APIs". But soon enough those few featured turned into full-on DBMSes, resulting in a DMBS in front of a DBMS. But then people, rightfully, started asking: "Why are we putting a DBMS in front of a DBMS?"

The trouble is that nobody took a step back and asked: "Can we simply use the backing DBMS?" Instead, they trudged forward with "Let's get rid of the backing DBMS and embed the database engine into our own DBMS!" And since SQLite is a convenient database engine...