Copy edit FAQs (github#767)

Co-authored-by: Lana Brindley <github@lanabrindley.com>

timescaledb/overview/faq/faq-postgres.md

@@ -8,10 +8,13 @@ Read our TimescaleDB-PostgreSQL benchmarks:
 To summarize, TimescaleDB offers:
 * Ease-of-use: TimescaleDB is far easier to use because creating partitions (or what we call
 "chunks") is automatically performed for the user. All of the complexity of automatic
-partitioning is abstracted away behind a "hypertable", which users interact with just as
+partitioning is abstracted away behind a hypertable, which users interact with just as
 they would with a PostgreSQL table.
-* Much higher ingest scale: TimescaleDB sees throughput more than 20X that of
-PostgreSQL once tables reach moderate size (e.g., 10s of millions of rows).
+* Much higher ingest scale: TimescaleDB sees throughput more than 20 times that of 
+<!-- vale Google.Units = NO -->
+PostgreSQL once tables reach moderate size (for example, tens of millions of
+rows). 
+<!-- vale Google.Units = YES -->
 While vanilla PostgreSQL is suitable for time-series data at low volumes, it does
 not scale well to the volume of data that most time-series applications produce, especially
 when running on a single server. In particular, vanilla PostgreSQL has poor write performance
@@ -33,16 +36,18 @@ and easily enforces data retention policies by specifying the data you wish to b
 deleted that is older than a specified time period. For more information, see [Data Retention][data-retention].
 * Extended time-oriented features: TimescaleDB includes time-series specific features
 not included in vanilla PostgreSQL and entirely unique to TimescaleDB
-(e.g., [`time_bucket`][time_bucket],[`first`][first] and [`last`][last]), with more to come.
+(such as [`time_bucket`][time_bucket],[`first`][first], and [`last`][last]), 
+with more to come.
 
 ## How compatible is TimescaleDB with PostgreSQL?
 TimescaleDB is implemented as an extension to PostgreSQL that introduces
 transparent scalability and performance optimizations, as well as time-series
-specific features (e.g., arbitrary aggregations, data retention policies). TimescaleDB
-connects with any and all third party tools that communicate with standard PostgreSQL
-connectors. TimescaleDB supports the same extensions, tools and drivers that PostgreSQL
-supports. You can continue to run your existing PostgreSQL databases and work with your
-current visualization and reporting tools.
+specific features (for example, arbitrary aggregations, data retention
+policies). TimescaleDB connects with any and all third-party tools that
+communicate with standard PostgreSQL connectors. TimescaleDB supports the same
+extensions, tools and drivers that PostgreSQL supports. You can continue to run
+your existing PostgreSQL databases and work with your current visualization and
+reporting tools.
 
 ## How does TimescaleDB handle geospatial data?
 As an extension of PostgreSQL, TimescaleDB works well with PostGIS. For example,

timescaledb/overview/faq/faq-products.md

@@ -148,7 +148,7 @@ Yes. TimescaleDB is currently deployed in production across a variety of industr
 including manufacturing, energy, utilities, mining, oil and gas, finance, ad tech,
 smart spaces, and more.
 
-## When is TimescaleDB a good choice?**  [](when-good)
+## When is TimescaleDB a good choice?  [](when-good)
 TimescaleDB is a good choice:
 
 * If you, and more of your organization, want to make standard SQL queries on time-series data,
@@ -168,9 +168,9 @@ natural queries.
 and inherits its support for varied datatypes and indexes (B-tree, hash, range, BRIN, GiST, GIN).
 * If support for geospatial data is desirable. Data stored in TimescaleDB can leverage PostGIS's
 geometric datatypes, indexes, and queries.
-* If you want greater optionality when it comes to using third-party tools. TimescaleDB supports
-anything that speaks SQL (i.e., the entire PostgreSQL ecosystem).
-* If you already use and like PostgreSQL, and don't want to have to "give it up" and move to a
+* If you want more options when it comes to using third-party tools. TimescaleDB supports
+anything that speaks SQL, including the entire PostgreSQL ecosystem.
+* If you already use and like PostgreSQL, and don't want to give it up and move to a
 NoSQL system in order to scale to larger volumes of data.
 * If you already chose to abandon PostgreSQL or another relational database for a Hadoop/NoSQL
 system due to scaling concerns or issues. We provide support for the migration back.
@@ -179,20 +179,21 @@ system due to scaling concerns or issues. We provide support for the migration b
 For this scenario, in-memory or column-oriented databases are designed for
 key-value storage with fast lookup and a relational database may not be ideal.
 However, these systems clearly do not scale to large data volumes and cannot
-perform well for more complex queries (whereas relational databases
-like TimescaleDB and PostgreSQL are better suited).
+perform well for more complex queries, where relational databases
+like TimescaleDB and PostgreSQL are better suited.
 
 ## What if I have very sparse or unstructured data?
-Good question. TimescaleDB leverages PostgreSQL support for JSON/JSONB formats
+TimescaleDB leverages PostgreSQL support for JSON/JSONB formats
 and handles sparsity quite efficiently (bitmaps for NULL values). However,
 there are some best practices and suggestions that may apply to get optimal
-performance depending on your scenario. Please see discussion in these docs
+performance depending on your scenario. See discussion in these docs
 or [join our Slack group][join_slack].
 
-[why-sql]: https://www.timescale.com/blog/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a
-[new-queries]: /how-to-guides/query-data/advanced-analytic-queries
+[distributed_hypertable]: /overview/core-concepts/distributed-hypertables/
 [join_slack]: https://slack.timescale.com/
-[timescale-license]: https://www.timescale.com/legal/licenses
+[new-queries]: /how-to-guides/query-data/advanced-analytic-queries
 [timescale-k8s]: https://github.com/timescale/timescaledb-kubernetes
+[timescale-license]: https://www.timescale.com/legal/licenses
 [timescale-signup]: https://www.timescale.com/timescale-signup
 [timescale-support]: https://www.timescale.com/support
+[why-sql]: https://www.timescale.com/blog/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a

timescaledb/overview/faq/faq-using-timescaledb.md

@@ -14,7 +14,7 @@ Owing to these advantages, TimescaleDB is currently deployed across a variety of
 including manufacturing, energy, utilities, mining, oil and gas, finance, ad tech, smart spaces,
 and more. Use cases include complex monitoring and analytics; predicting the performance and
 behavior of applications, models, consumers and connected machines; powering operational
-analytical workflows and dashboards; for QA and performance testing.
+analytical workflows and dashboards; and QA and performance testing.
 
 ## How do I write data?
 Just via normal SQL, but here are some [insert examples][INSERT].
@@ -30,8 +30,8 @@ compression algorithms for timestamps, integers, floats, strings, or other
 data). Many users see between a 90-98% reduction in their storage footprint,
 leading to significant cost savings (and other query performance improvements).
 Note that compression must be *explicitly turned on and configured* for a
-hypertable; compression is by default off. For more details about how to use
-TimescaleDB ncompression, please see [our compression docs][compression-docs]
+hypertable; compression is off by default. For more details about how to use
+TimescaleDB compression, please see [our compression docs][compression-docs]
 or a longer technical deep-dive [on our blog ][compression-blog].
 
 ## How far can TimescaleDB scale?
@@ -42,7 +42,7 @@ Multi-node TimescaleDB can scale to 10+ million metric inserts / second, and
 store petabytes of data. You can read more about
 [insert and query benchmarks][benchmarks] for multi-node TimescaleDB.
 
-TimescaleDB is designed to combine the scalability of popular NoSQL databases,
+TimescaleDB is designed to combine the scalability of popular NoSQL databases
 with the native query complexity supported by RDBMS systems. Read on for more
 details on clustering.
 
@@ -54,7 +54,7 @@ as writes (inserts) to the latest time intervals, not as updates to existing rec
 * Workloads have a natural partitioning across both time and space.
 
 TimescaleDB leverages these properties by automatically partitioning data into
-two-dimensional "chunks" (i.e., smaller PostgreSQL tables), performing
+two-dimensional chunks that operate like smaller PostgreSQL tables, performing
 operations and optimizing query planning across all chunks. This partitioning of the
 data into chunks ensures that recent tables' indexes are kept in memory as data is inserted
 into the database. Yet all this complexity is abstracted away from the user and