3 ms·
As many others already stated, there are more than just small subtle differences that will bite you with this approach. Eventually forcing you to develop unnece
by Too 2y ago
As many others already stated, there are more than just small subtle differences that will bite you with this approach. Eventually forcing you to develop unnecessary compatibility abstractions or downgrade to less efficient lowest common denominator feature set to make it work. It's not worth the effort.
Especially since launching postgres is equally easy and fast as sqlite. Docker can help with sandboxing. What is left to gain? 100ms shorter startup time or keeping your unit test executables as single binaries? Irrelevant.
- anarazel 2y ago> Especially since launching postgres is equally easy and fast as sqlite It's definitely not as fast to start postgres as it is to start sqlite. Pretty much inherently - postgres has to fork a bunch of processes, establishes network connectivity etc. And running trivial queries will always be faster with sqlite, because executing queries via postgres will require intra-process context switches. That's not to say postgres is bad (I've worked on it for most of my career), but there just are inherent advantages and disadvantages of in-process databases vs out-of-process databases. And lower startup time and lower "dispatch" overhead are advantages of in-process databases.