The "isolation" part is a bit sloppy: that's what happens if you are using the "serializable" isolation level in SQL speak. But that's often not the default, because guaranteeing a serializability is hard for the database engine.
As I remember it, SQLite enforces serializability by default (and maybe as its only option), but with a hard price: when a transaction is writing, the whole database is exclusively locked by that transaction; the other transactions cannot even read.
PostgreSQL allows serializability, though not by default (I think). It's more advanced than SQLite, as it can have more reading and writing transactions at the same time, but any of them might fail if at some point the database engine is not able any more to keep the illusion of serialization. So the application must be ready to retry the transaction from the beginning, if required.
Serializability is very desirable for the application, because it has the following property: "If each transaction transforms the database in a consistent way, the database will always remain consistent". But that's difficult to do with concurrent transactions (unless you're able to predict future), so you should be aware of the associated compromises.
PostgreSQL has some interesting documentation on this problem: https://www.postgresql.org/docs/9.5/transaction-iso.html.
A series of tweets (having the noise of Twitter around it) is now the new blogging? It certainly does not qualify as a 'Show HN'.
Anyways, this seems just an ad as it ends with:
'Here's a great course by @XXXX that helped me grow my Twitter account from 150 -> ~20k followers in 11 months:'