Your SQL server runs as a service to connect to, your sqlite3 file is a file that you need access to. If your server or API can be exploited, it doesn't matter whether there's an auth layer in between. But without that firewall, the question becomes: how much of the data in my SQLite can now be trusted? If you don't know what backup is safe to restore, then you can't trust any of it.Īgain, this is about layers. With a separate DB you may have a hope of detecting when someone hacked your app. That's only going to help if the hacker totally trashes your DB. This is why you can't simply rely on the idea of using a backup. Especially if they are doing something subtle like UPDATEs on specific tables/fields that may go unnoticed but provide the hacker some benefit. If someone hacks your SQLite app they may have access for months before you realize it, if you ever do. In addition, with a separate DB process you get audit logs. With SQLite, if your app gets hacked then they can do anything with the whole DB they want to. You can, for example, put DELETEs or access to certain tables on a separate user that your web app has no access to.
Security is about layers, and SQLite is removing one layer of security. MySQL/PostgreSQL have users and permissions.
Connect to sqlite database full#
Your app has full access to the SQLite file. I love SQLite, and use it regularly, just not for production web services. This system has been up for four years at this point, with no downtime. I run many SQL backed production services, and my sweet spot has become a big honking Postgres instance in RDS in AWS, with WAL streaming based replicas for instant failover in case of outage, and read replicas, also via WAL. Now, for streaming backups - how do you come back from node failure? You're going to incur downtime downloading your DB. SQLite has very limited DDL operations, so you also can't evolve your schema over time without downtime. The moment you need multiple backends to handle more load, or the moment you need high availability, you can't do it with SQLite. SQLite is fine when all your load can be served by a single backend process on a single machine. It's faster because those other features of a server have a cost as well, particularly the cost of write arbitration. SQLite is far faster than Postgres or MySQL, however, the price you pay for this is having a single writer thread, and it's a library incorporated into your process, not a shared DB.
0 kommentar(er)
