Add SEO blog posts: what is a database + what is a database index#3028
Add SEO blog posts: what is a database + what is a database index#3028atharvadeosthale wants to merge 6 commits into
Conversation
Two long-form educational posts targeting top-of-funnel search terms. Both currently unlisted; covers generated via cover.appwrite.network.
Appwrite WebsiteProject ID: Website (appwrite/website)Project ID: Tip Sites auto-generate unique domains with the pattern https://randomstring.appwrite.network |
Greptile SummaryAdds two new unlisted SEO blog posts targeting top-of-funnel search terms: a primer on what a database is (types, picking one, Appwrite TablesDB) and a guide to database indexes (types, worked example, when to add/avoid them). Both posts are shipped as
Confidence Score: 5/5Two new unlisted blog posts and their static cover images; no runtime logic, no schema changes, and no API changes are involved. The change is purely additive content — new markdoc files and image assets behind
Important Files Changed
Reviews (3): Last reviewed commit: "Merge branch 'main' into atharva/databas..." | Re-trigger Greptile |
Moves TablesDB into its own dedicated category instead of bucketing it under NoSQL, adds Collections and Documents subsections, simpler customer/orders example, race-condition explanation, and tilts the database picker section toward Appwrite.
Avoids confusion with Appwrite's system $createdAt field, which cannot be used in a manual composite index, by using an unambiguously user-defined column throughout the worked example.
Co-authored-by: Atharva Deosthale <atharva.deosthale17@gmail.com>
| - question: "What is a database index in simple words?" | ||
| answer: "A database index is a sorted, lookup-optimized copy of one or more columns from a table, with pointers back to the rows. It lets the database find matching rows quickly instead of reading every row to check. The analogy is the index at the back of a book: you find the topic in a sorted list and jump to the right page, instead of reading the whole book." | ||
| - question: "Why do databases use indexes?" | ||
| answer: "Without an index, the database has to perform a full table scan, checking every row to see whether it matches the query. Even on modest tables that becomes slow as data grows. An index reduces the work from \"check every row\" to \"jump to the matching range\", which is the difference between a query that takes seconds and one that takes milliseconds." | ||
| - question: "What are the main types of database indexes?" | ||
| answer: "The common ones are single-column indexes for filtering and sorting on one column, composite indexes covering several columns together, unique indexes that enforce no duplicates, full-text indexes for searching text content, spatial indexes for geographic data, hash indexes for exact-match key lookups, and vector indexes for similarity search in AI applications." | ||
| - question: "Does adding more indexes always make a database faster?" | ||
| answer: "No. Indexes speed up reads but slow down writes. Every insert, update, or delete has to update every index on the table. A table with too many redundant indexes pays a heavy write cost without a matching read benefit. Add indexes for queries you do run, and drop ones that no query uses." | ||
| - question: "What is the difference between a primary key and an index?" | ||
| answer: "A primary key uniquely identifies a row in a table and is almost always backed by an index automatically. An index is the underlying data structure that makes lookups fast. So a primary key is one specific use of an index, but you can also create plenty of additional indexes on non-key columns to speed up other queries." | ||
| - question: "When should I create a composite index?" | ||
| answer: "Create a composite index when your queries consistently filter or sort on the same combination of columns. For example, if you regularly query posts by status and authorId together, a composite index on (status, authorId) is more efficient than two separate single-column indexes. The order of columns matters: a (status, authorId) index helps filtering on status alone or status plus authorId, but not authorId alone." |
There was a problem hiding this comment.
Let's add Appwrite-specific FAQs too
|
|
||
| Add a composite index on `(status, publishedAt)` (descending), and the database can walk directly to the published rows in `publishedAt` order and stop after ten. The same query goes from seconds to milliseconds, with no change to the application code. | ||
|
|
||
| That is the whole pitch of indexes in one example. The query did not change. The work the database had to do did. |
There was a problem hiding this comment.
Sentences like these are a little too AI
| - question: "What is a database in simple words?" | ||
| answer: "A database is an organized place where an application stores information so it can be searched, updated, and shared later. Think of it as a digital filing system designed for fast lookups instead of paper folders and drawers." | ||
| - question: "What are the main types of databases?" | ||
| answer: "The most common types developers work with are relational databases like PostgreSQL and MySQL, document databases like MongoDB and CouchDB, key-value stores like Redis and DynamoDB, and vector databases used for AI and semantic search. Appwrite TablesDB sits alongside these as a managed, relational-style API layer that gives you tables, rows, and columns through every Appwrite SDK without running a database server." | ||
| - question: "What is the difference between a database and a spreadsheet?" | ||
| answer: "A spreadsheet is a single file optimized for one person to view and edit data manually. A database is a service that supports many users and apps reading and writing the same data at once, enforces structure, runs efficient queries on millions of rows, and protects data with permissions and transactions." | ||
| - question: "What is the difference between SQL and NoSQL databases?" | ||
| answer: "SQL databases store data in strict tables with predefined columns and use SQL to query them. NoSQL databases relax that structure: documents can have different fields, key-value stores hold one value per key, and so on. SQL is a strong default when relationships matter. NoSQL is a strong default when the shape of your data changes often or you need to scale writes horizontally." | ||
| - question: "Which database should I use for my app?" | ||
| answer: "Start from your data shape and your query patterns. If your data has clear relationships and you need joins, pick a relational database. If you store flexible JSON-like records, pick a document database. If you need millisecond lookups by a single key, pick a key-value store. If you are building an AI feature that searches by meaning, add a vector database. If you want one managed platform that handles auth, storage, functions, and a relational-style database together, Appwrite TablesDB is built for that." | ||
| - question: "Do I need to know SQL to use a database?" | ||
| answer: "Not always. SQL is still the most widely used query language, and learning the basics is worth the time. But many modern databases, including Appwrite TablesDB, expose a higher-level query API in your SDK of choice, so you can read and write rows without writing raw SQL strings." |
There was a problem hiding this comment.
Let's add Appwrite-specific FAQs too (questions, not just answers)


Two long-form educational posts targeting top-of-funnel search terms ("what is a database" and "what is a database index"), drafted from SERP + competitor analysis to fill content gaps in top-ranking pages.
Both shipped as
unlisted: truefor now; covers generated via cover.appwrite.network.