Using SQLite in Production

… ## Cons of Using SQLite in Production: **Concurrency Issues:** SQLite is not ideal for applications with a high level of concurrent write operations. It locks the entire database during a write operation, which can cause a bottleneck. *If we're working on a single threaded application since we're talking about smaller applications without too much traffic, this will not really be an issue. However, it does bring up a good point for any kind of background workers that occur asynchronous. Even though SQLite does a good job at handling transactions, it is easy to get ourselves into situations of Deadlocks when background jobs are trying to write to the database at the same time.* **Not Suited for Large Databases:** While SQLite supports database files up to 140 TB, it’s generally not the best choice for very large datasets due to potential performance issues. *Most databases will never reach 140TB. But this does not talk to file system limits. This is really a moot point since modern file systems exceed SQLite's limits, but if you're file system was improperly set (to something like Fat32), then you could easily reach the 4GB limit. Most likely, if your database was even getting to a fraction of this size, you'll have other issues to be concerned with; system resources, performance issues, etc.* **Limited Built-in Features:** Unlike more robust RDBMS like PostgreSQL or MySQL, SQLite doesn’t have a wide range of built-in tools or support for stored procedures, right out of the box. *It supports the important ones like JSON data types. Typically, we don't use stored procedures in Ruby on Rails applications since the ActiveRecord ORM is powerful enough in most cases.* **Limited Security:** SQLite doesn’t have built-in support for user management or access control, making it less secure than other RDBMS. *While this can be a critical aspect in some scenarios, the Ruby on Rails applications will likely not need this level of access control. However, it does speak to the vulnerability of the database as it will be much easier to make a copy of if the system is ever breached. … **No Client-Server Model:** SQLite doesn’t have a client-server model, which means it can’t be accessed by multiple users at the same time. *This is going to be a big issue if High Availability is a concern. Typically, we will have a load balancer as the SSL termination point and it will route the traffic to one of the available web servers. This is a deal breaker in many situations as using SQLite in a production setting could mean that you have downtime during deployments. You lose the ability for rolling deployments and have basically put all eggs in one basket. Depending on your deployment strategy, it could also mean that you're having to maintain a server instead of being able to manually or automatically provision and scale up new web servers.* … You can get a lot of value out of these services and it will be much easier to scale up in the future if you need to. I think that the biggest concern is the lack of High Availability This is a deal breaker for most applications that are going to be deployed in a production setting. However, for non-revenue generating applications or applications that are not mission critical, SQLite could be a good choice.