If I was going to give folks advice, it would be to use an ORM, instead. That let me build low-investment prototypes using SQLite. When I outgrew it, I could easily switch to PostgreSQL by adding the appropriate test framework plugin and changing the database connection string.
SQLite, for all it's features, has some pretty significant limits. In my case, I needed better date/time and decimal type handling than what's on offer in SQLite. I still test my code against SQLite because that is a useful way to lint my data model—plus it's nice for small-scale proof-of-concept deployments—but I expect deployers to use PostgreSQL or MariaDB in production.
Edit: I've had a chance to read the article. The comment about "zero latency" is wrong because it ignores disk I/O. And yes, I know SSDs are super fast. Still not zero. The bit about Docker Compose rings hollow. It sounds like they need to learn how to use multiple Compose files, e.g., https://mindbyte.nl/2018/04/04/overwrite-ports-in-docker-com.... As for development and testing, mock database setup should be handled by your unit test framework. I'm familiar with pytest, which makes testing the same model or ETL across multiple database fixtures very, very easy. SQLite has nothing to do with that.
SQLite, for all it's features, has some pretty significant limits. In my case, I needed better date/time and decimal type handling than what's on offer in SQLite. I still test my code against SQLite because that is a useful way to lint my data model—plus it's nice for small-scale proof-of-concept deployments—but I expect deployers to use PostgreSQL or MariaDB in production.
Edit: I've had a chance to read the article. The comment about "zero latency" is wrong because it ignores disk I/O. And yes, I know SSDs are super fast. Still not zero. The bit about Docker Compose rings hollow. It sounds like they need to learn how to use multiple Compose files, e.g., https://mindbyte.nl/2018/04/04/overwrite-ports-in-docker-com.... As for development and testing, mock database setup should be handled by your unit test framework. I'm familiar with pytest, which makes testing the same model or ETL across multiple database fixtures very, very easy. SQLite has nothing to do with that.