Update docs and blogs to TablesDB terminology

[atharvadeosthale]

Summary

• Reworked docs and blog content to replace legacy databases terminology with current tables, rows, and columns language where appropriate
• Updated SDK examples to use object-based params across the supported languages, and corrected a few snippets that needed signature-specific field ordering
• Kept API references and legacy linkage plumbing intact where they are generated or intentionally preserved

Testing

• Node SDK object-param payloads were smoke-tested against the generated SDK
• Changed JS/TS/Deno code fences were parsed successfully
• Repo checks passed, including bun run check and diff whitespace validation

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

Site	Status	Logs	Preview	QR
website 69d7f2670014e24571ca	Building	View Logs	Preview URL

Website (appwrite/website)

Project ID: 684969cb000a2f6c0a02

Sites (1)

Site	Status	Logs	Preview	QR
website 68496a17000f03d62013	Queued	View Logs	Preview URL

---

Tip

Build commands execute in runtime containers during deployment

[adityaoberai]

Please check for patterns of these issues across other blogs

Also, for every blog edited, we need to update the lastUpdated field in the frontmatter

[adityaoberai]

We will need to update the function template as well for this to work properly

Also, let's not remove the events from there, we should mention the correct ones instead

[adityaoberai]

Suggested change

	1. **[Appwrite Function Docs](https://appwrite.io/docs/functions)**: Learn more about how to use Appwrite Functions.
	1. **[Appwrite Function Docs](/docs/products/functions)**: Learn more about how to use Appwrite Functions.

[adityaoberai]

Suggested change

	1. **[Appwrite Function Docs](https://appwrite.io/docs/functions)**: Learn more about how to use Appwrite Functions.
	1. **[Appwrite Function Docs](/docs/products/functions)**: Learn more about how to use Appwrite Functions.

[adityaoberai]

Suggested change

	3. **[Appwrite Discord](https://discord.com/invite/appwrite)**: Connect with other developers and the Appwrite team for discussion, questions, and collaboration.
	3. **[Appwrite Discord](/discord)**: Connect with other developers and the Appwrite team for discussion, questions, and collaboration.

[adityaoberai]

Suggested change

	3. **[Appwrite Discord](https://discord.com/invite/appwrite)**: Connect with other developers and the Appwrite team for discussion, questions, and collaboration.
	3. **[Appwrite Discord](/discord)**: Connect with other developers and the Appwrite team for discussion, questions, and collaboration.

[adityaoberai]

This does not need a change, does it?

[adityaoberai]

Changes are unnecessary imho

[adityaoberai]

formatting issues?

[adityaoberai]

These changes should not have been made in this PR, they add lots of extra bloat to review

Any changes to switch to object params should have been in a separate PR

[adityaoberai]

not the right phrasing, we should just say they accept JSON inputs that are mapped to the table schema

[atharvadeosthale]

@greptile-apps review

[greptile-apps]

Greptile Summary

This PR migrates 204 docs and blog files from the legacy Appwrite Databases terminology (collections, documents, attributes) to the current TablesDB terminology (tables, rows, columns), and simultaneously updates SDK code examples to use object-based named parameters in place of positional arguments across JavaScript, TypeScript, Python, Ruby, and Deno tabs.

• Terminology sweep: Every reference to "collection", "document", and "attribute" across docs, quick-starts, and blog posts is replaced with "table", "row", and "column"; API references and legacy linkage plumbing are intentionally preserved.
• SDK snippet migration: listRows, createRow, updateRow, upsertRow, deleteRow, createRows, updateRows, upsertRows, deleteRows, incrementRowColumn, and decrementRowColumn examples are updated to the object-param style across all supported languages.
• Notable concerns: One benchmark script directly accesses MariaDB with a bare table name (posts) instead of the Appwrite-internal prefixed format; a Flutter tutorial drops the size constraint when changing a column from String to Text, which is inconsistent with how the same "Text" type is documented in the quick-start page.

Confidence Score: 3/5

Two tutorial code spots introduce misleading or broken instructions that readers could follow and get stuck on; the remaining ~202 files are safe.

The MariaDB INSERT in the pagination benchmark explicitly bypasses the SDK and writes directly to the underlying database; using a bare table name (posts) rather than Appwrite's actual internal table identifier would silently fail for any reader trying to reproduce the benchmark. The Flutter tutorial also drops the required size field when switching a column from String to Text, while the quick-start page changed in this same PR still instructs readers to enter a size.

src/routes/blog/post/best-pagination-technique/+page.markdoc (direct MariaDB table name) and src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc (missing column size) need a second look.

Important Files Changed

Filename	Overview
src/routes/blog/post/best-pagination-technique/+page.markdoc	Pagination code updated to TablesDB API and correct variable names; however the direct MariaDB INSERT table name was incorrectly changed from the Appwrite internal format to a bare posts table name
src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc	Flutter SDK calls migrated to TablesDB API (listRows, createRow, deleteRow); column type changed from String/size 25 to Text without size, which is inconsistent with quick-start docs
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc	Full migration to TablesDB API across imports and SDK calls; userId column changed to Text instead of the more appropriate Varchar for an indexable ID field
src/routes/blog/post/ai-crystal-ball/+page.markdoc	SDK migrated to TablesDB, column types updated correctly, file path typo fixed, addDestiny/getDestiny functions correctly rewritten
src/routes/docs/products/databases/quick-start/+page.markdoc	Updated UI instructions from 'String' to 'Text' column type and CLI command updated; size requirement text kept intact
src/routes/docs/products/databases/rows/+page.markdoc	SDK calls updated to object-based params, variable renamed from doc to row, CLI command updated; changes look consistent and correct
src/routes/docs/products/databases/queries/+page.markdoc	Python/Ruby keyword-arg format added, variable names changed from doc to row, 'string operations' renamed to 'text operations'; well-aligned changes
src/routes/docs/products/databases/bulk-operations/+page.markdoc	JS/TS bulk row methods migrated to object-based params; consistent with SDK changes
src/routes/docs/products/databases/relationships/+page.markdoc	createRelationshipColumn migrated from positional to named-object params; field names correctly renamed
src/routes/docs/products/databases/tables/+page.markdoc	Column type descriptions updated (varchar now described as 'Short text column'); accurate terminology change

Comments Outside Diff (1)

1. src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc, line 56-62 (link)

   Size field removed for a Text column type that still requires a size per the quick-start docs

   The name column changed from Type: String, Size: 25 to Type: Text with the Size line dropped entirely. However, in docs/products/databases/quick-start/+page.markdoc (also changed in this PR), the updated instruction for creating a "Text" column still reads: "Enter Column key and Size. For example, title and 100." — meaning "Text" type columns still require a size to be specified. Omitting the size here leaves a reader without a value to enter and silently changes the semantic: if "Text" maps to the large text column type rather than varchar, the field loses its 25-character size cap and can no longer be fully indexed, which would affect any query that filters or sorts by name.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc
   Line: 56-62
   
   Comment:
   **Size field removed for a Text column type that still requires a size per the quick-start docs**
   
   The `name` column changed from `Type: String, Size: 25` to `Type: Text` with the `Size` line dropped entirely. However, in `docs/products/databases/quick-start/+page.markdoc` (also changed in this PR), the updated instruction for creating a "Text" column still reads: *"Enter **Column key** and **Size**. For example, `title` and `100`."* — meaning "Text" type columns still require a size to be specified. Omitting the size here leaves a reader without a value to enter and silently changes the semantic: if "Text" maps to the large `text` column type rather than `varchar`, the field loses its 25-character size cap and can no longer be fully indexed, which would affect any query that filters or sorts by name.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
src/routes/blog/post/best-pagination-technique/+page.markdoc:173
**Incorrect internal MariaDB table name in direct-SQL benchmark script**

The benchmark blog explicitly states it bypasses the Appwrite SDK and inserts directly into MariaDB: *"We could use Appwrite SDK, but talking directly to MariaDB offers more optional write queries for large datasets."* The old name `_project_${config.projectId}_collection_posts` was the actual internal naming convention Appwrite used when storing collection data. Changing it to just `posts` is almost certainly wrong — in any Appwrite version, including TablesDB, the underlying MariaDB table would have a namespace prefix, not the bare user-supplied table ID. A reader who follows this script verbatim to reproduce the benchmark would execute the INSERT against a non-existent table or the wrong table entirely.

### Issue 2 of 3
src/routes/blog/post/appwrite-realtime-for-flutter/+page.markdoc:56-62
**Size field removed for a Text column type that still requires a size per the quick-start docs**

The `name` column changed from `Type: String, Size: 25` to `Type: Text` with the `Size` line dropped entirely. However, in `docs/products/databases/quick-start/+page.markdoc` (also changed in this PR), the updated instruction for creating a "Text" column still reads: *"Enter **Column key** and **Size**. For example, `title` and `100`."* — meaning "Text" type columns still require a size to be specified. Omitting the size here leaves a reader without a value to enter and silently changes the semantic: if "Text" maps to the large `text` column type rather than `varchar`, the field loses its 25-character size cap and can no longer be fully indexed, which would affect any query that filters or sorts by name.

### Issue 3 of 3
src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc:100-107
**`userId` column changed from `String` to `Text` — a short ID field should be `Varchar`**

`userId` is a short identifier (typically ≤ 36 characters for a UUID) that callers will almost certainly filter on (e.g., `Query.equal('userId', currentUser.$id)`). The `varchar` / "Short text" type is fully indexable up to 768 characters and is the correct pick for this field. The `text` column type uses prefix indexing only, cannot be fully indexed, and has no effective size constraint. If this "Text" instruction maps to the `text` column type in the new Console UI, the tutorial inadvertently guides readers to create a column that cannot be efficiently queried by user ID.

_{Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile}

[greptile-apps]

Incorrect internal MariaDB table name in direct-SQL benchmark script

The benchmark blog explicitly states it bypasses the Appwrite SDK and inserts directly into MariaDB: "We could use Appwrite SDK, but talking directly to MariaDB offers more optional write queries for large datasets." The old name _project_${config.projectId}_collection_posts was the actual internal naming convention Appwrite used when storing collection data. Changing it to just posts is almost certainly wrong — in any Appwrite version, including TablesDB, the underlying MariaDB table would have a namespace prefix, not the bare user-supplied table ID. A reader who follows this script verbatim to reproduce the benchmark would execute the INSERT against a non-existent table or the wrong table entirely.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/routes/blog/post/best-pagination-technique/+page.markdoc
Line: 173

Comment:
**Incorrect internal MariaDB table name in direct-SQL benchmark script**

The benchmark blog explicitly states it bypasses the Appwrite SDK and inserts directly into MariaDB: *"We could use Appwrite SDK, but talking directly to MariaDB offers more optional write queries for large datasets."* The old name `_project_${config.projectId}_collection_posts` was the actual internal naming convention Appwrite used when storing collection data. Changing it to just `posts` is almost certainly wrong — in any Appwrite version, including TablesDB, the underlying MariaDB table would have a namespace prefix, not the bare user-supplied table ID. A reader who follows this script verbatim to reproduce the benchmark would execute the INSERT against a non-existent table or the wrong table entirely.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

userId column changed from String to Text — a short ID field should be Varchar

userId is a short identifier (typically ≤ 36 characters for a UUID) that callers will almost certainly filter on (e.g., Query.equal('userId', currentUser.$id)). The varchar / "Short text" type is fully indexable up to 768 characters and is the correct pick for this field. The text column type uses prefix indexing only, cannot be fully indexed, and has no effective size constraint. If this "Text" instruction maps to the text column type in the new Console UI, the tutorial inadvertently guides readers to create a column that cannot be efficiently queried by user ID.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/routes/blog/post/build-fullstack-svelte-appwrite/+page.markdoc
Line: 100-107

Comment:
**`userId` column changed from `String` to `Text` — a short ID field should be `Varchar`**

`userId` is a short identifier (typically ≤ 36 characters for a UUID) that callers will almost certainly filter on (e.g., `Query.equal('userId', currentUser.$id)`). The `varchar` / "Short text" type is fully indexable up to 768 characters and is the correct pick for this field. The `text` column type uses prefix indexing only, cannot be fully indexed, and has no effective size constraint. If this "Text" instruction maps to the `text` column type in the new Console UI, the tutorial inadvertently guides readers to create a column that cannot be efficiently queried by user ID.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[adityaoberai]

Approving to unblock