3 ms·

> It is my understanding that something about not having to take a network hop and being able to directly invoke the database methods makes a huge difference. A

by gfody 5y ago

> It is my understanding that something about not having to take a network hop and being able to directly invoke the database methods makes a huge difference. Are you able to execute queries and reliably receive results within microseconds with your current database setup? with SQL Server you can get a very fast local connection by specify "server=(local)" in the connection string - this uses shared memory protocol bypassing the net stack.

bob1029 5y ago
This is true - The counterpoint is that now you have this leviathan that is the SQL Server process(es) running on the same machine as the application. If I am constraining my SQL Server usage to fit on 1 box, I might as well use SQLite (assuming no future plans for horizontal scaling).
- devwastaken 5y ago
  How is this handling privledge separation? Typically you'd have all accesses as root in SQLite.
  - usrbinbash 5y ago
    >Typically you'd have all accesses as root in SQLite. So? It's the backend talking to the db.
    - devwastaken 5y ago
      Systems of least privilege prevent the levels of access exploitation (either vuln or misconfigure) from going further than is risk assessed. Or from "accidents" like a little utility script nuking the database with root privilege. Or having multiple entry points with their own tables of data. That's the difference between "hackers stole X but not Y and Z" and "hackers dumped everything". Your "backend" should not be assumed to be the infallible security. Outside of limiting DB access procledges, we have proper selinux and other configs to lock down the software abilities so even in the case of Arbitrary code execution caused by a common exploit it may be very difficult to use. This is important when you're running a box with multiple other applications with their own DB's as well. Infact these reasons are why many times the "backend" software and DB are hardware isolated or at least VM isolated so that those db access limitations aren't bypassed.
      - hnfong 5y ago
        I haven't done anything like this before, but simple FS level file permissions should resolve the issue as long as the data with separate priv requirements is put into different sqlite databases.
chasil 5y ago
Oracle clients can do the same by setting the ORACLE_SID and ORACLE_HOME environment variables. For remote databases, setting the TWO_TASK environment variable to the server's TNS descriptor is one way to force a network login.

by gfody 5y ago

bob1029 5y ago

This is true - The counterpoint is that now you have this leviathan that is the SQL Server process(es) running on the same machine as the application. If I am constraining my SQL Server usage to fit on 1 box, I might as well use SQLite (assuming no future plans for horizontal scaling).

devwastaken 5y ago
How is this handling privledge separation? Typically you'd have all accesses as root in SQLite.
- usrbinbash 5y ago
  >Typically you'd have all accesses as root in SQLite. So? It's the backend talking to the db.
  - devwastaken 5y ago
    Systems of least privilege prevent the levels of access exploitation (either vuln or misconfigure) from going further than is risk assessed. Or from "accidents" like a little utility script nuking the database with root privilege. Or having multiple entry points with their own tables of data. That's the difference between "hackers stole X but not Y and Z" and "hackers dumped everything". Your "backend" should not be assumed to be the infallible security. Outside of limiting DB access procledges, we have proper selinux and other configs to lock down the software abilities so even in the case of Arbitrary code execution caused by a common exploit it may be very difficult to use. This is important when you're running a box with multiple other applications with their own DB's as well. Infact these reasons are why many times the "backend" software and DB are hardware isolated or at least VM isolated so that those db access limitations aren't bypassed.
    - hnfong 5y ago
      I haven't done anything like this before, but simple FS level file permissions should resolve the issue as long as the data with separate priv requirements is put into different sqlite databases.

chasil 5y ago

Oracle clients can do the same by setting the ORACLE_SID and ORACLE_HOME environment variables. For remote databases, setting the TWO_TASK environment variable to the server's TNS descriptor is one way to force a network login.