db post: better pinpoint sqlite unsuitability

1 files changed, 6 insertions, 6 deletions

diff --git a/_posts/2020-08-31-the-database-i-wish-i-had.md b/_posts/2020-08-31-the-database-i-wish-i-had.md
index f16cd38..2b57aae 100644
--- a/_posts/2020-08-31-the-database-i-wish-i-had.md
+++ b/_posts/2020-08-31-the-database-i-wish-i-had.md
@@ -80,12 +80,12 @@ that would have to be emulated~~[^posix-sqlite].
 
     That's not to say that adding an IndexedDB compatibility layer to SQLite
     would be enough to make it fit the other requirements I mention on this
-    page. SQLite still is an implementation of a relational, SQL, table-oriented
-    database. It is probably true that cherry-picking the relevant parts of
-    SQLite (like storage access, consistency, crash recovery, parser generator,
-    etc.) and leaving out the unwanted parts (SQL, tables, FTS, etc.) would be
-    better than including the full SQLite stack, but that's simply an
-    optimization. Both could even coexist, if desired.
+    page. SQLite still is an implementation of a update-in-place, SQL,
+    table-oriented database. It is probably true that cherry-picking the
+    relevant parts of SQLite (like storage access, consistency, crash recovery,
+    parser generator, etc.) and leaving out the unwanted parts (SQL, tables,
+    threading, etc.) would be better than including the full SQLite stack, but
+    that's simply an optimization. Both could even coexist, if desired.
 
     SQLite would have to be treated similarly to how Datomic treats SQL
     databases: instead of having a table for each entities, spread attributes