RDBMS parallelism

[sundaresh...@gmail.com]

Is there a practical limit to the number of process's/threads that can somewhat simultaneously access an RDBMS ? I am assuming that to access an RDBMS a process/thread first establishes a connection to a local or a remote RDBMS and acquires a connection handle to the RDBMS, access's the RDBMS and performs all its transactions using that connection handle, assuming a single RDBMS can have many schemes and many tables within a scheme, and then finally closes its connection. So is the background database process or daemon which can act as a server preferable, where the client library always communicates with the relevant server or is a simple shared library using shared memory preferable. If the number of such connections that can be established can be large then the client-server model might necessarily have to be used.

[Jasen Betts]

On 2020-04-02, sundaresh...@gmail.com <sundaresh...@gmail.com> wrote:
> Is there a practical limit to the number of process's/threads that
> can somewhat simultaneously access an RDBMS ?

It mostly depends how much you want to spend.

--
Jasen.

[sundaresh...@gmail.com]

On Friday, April 3, 2020 at 10:32:41 AM UTC+5:30, Jasen Betts wrote:
> > Is there a practical limit to the number of process's/threads that
> > can somewhat simultaneously access an RDBMS ?
>
> It mostly depends how much you want to spend.
>
> --
> Jasen.

Time and Effort already quite a lot and am willing to do more, but have an up and coming fairly OK system which I am pretty proud of. Will work equally well as a DRDBMS with fragmentation and so forth, but in terms of money, zilch.