db post: improve wording of posix-sqlite note

1 files changed, 7 insertions, 7 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 4ba1885..73423ce 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
@@ -83,20 +83,20 @@ that would have to be emulated~~[^posix-sqlite].
     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 using of all it just to building on top of the whole SQLite
-    stack, but that's simply an optimization. Both could even coexist, if
-    desired.
+    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.
 
     SQLite would have to be treated similarly to how Datomic treats SQL
     databases: instead of having a table for each entities, spread attributes
     over the tables, etc., it treats SQL databases as a key-value storage so it
-    doesn't have to re-implement interacting with the disk.
+    doesn't have to re-implement interacting with the disk that other databases
+    do well.
 
     The tables would contain blocks of binary data, so there isn't a difference
     on how the SQLite storage backend behaves and how the IndexedDB storage
-    backend behaves, much like Datomic works the same regardless of the storage
-    backend, same for PouchDB.
+    backend behaves, much like how Datomic works the same regardless of the
+    storage backend, same for PouchDB.
 
     I welcome corrections on what I said above, too.