From 93d807c7187f727af08f307279793ca888d472c2 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Mon, 20 Jul 2026 16:47:49 +0530 Subject: [PATCH 01/18] seo blogs for init --- .optimize-cache.json | 2 + .../+page.markdoc | 125 ++++++++++ .../+page.markdoc | 221 ++++++++++++++++++ .../cover.avif | Bin 0 -> 8427 bytes .../cover.avif | Bin 0 -> 6457 bytes 5 files changed, 348 insertions(+) create mode 100644 src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc create mode 100644 src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc create mode 100644 static/images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.avif create mode 100644 static/images/blog/sql-explained-how-developers-query-databases/cover.avif diff --git a/.optimize-cache.json b/.optimize-cache.json index 828a3aaef7..4598314011 100644 --- a/.optimize-cache.json +++ b/.optimize-cache.json @@ -852,6 +852,7 @@ "static/images/blog/manage-user-permissions-with-labels-and-teams/labels4.png": "b5b5d3c2be622e9c096d5977559e3a26ca2b5fa7ed3b0f81a5ab24e4b1fdc88b", "static/images/blog/manage-user-permissions-with-labels-and-teams/labels5.png": "bee498d03d3391524aa5ee6c574febfd3f881e3a4cbfe9498e7e8389574025be", "static/images/blog/manage-user-permissions-with-labels-and-teams/labels6.png": "02bd833be8556be4a2b1c557a495339fe74403b2254781b43a5e04ed1431f71f", + "static/images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.png": "9eea0d555454fd5e43141b78bbd1f9484face6eb94f4ecd9141afb82c927a3ca", "static/images/blog/managing-website-assets-repo-cold-start/cover.png": "ff11c54070d4662b6cde70e1b95c8a944e382e353928a68dae5e2baa45ba3b73", "static/images/blog/master-prompt-engineering-tools/cover.png": "4ca1cedae3df550ee8b3613ebbd4643f02f1ad60fc9bf46a5d06c344497d5662", "static/images/blog/master-prompt-engineering-tools/langchain.png": "3366f36adeb0d73b75aa0ead5d8f47ae26a19bbcceeb4ed89b6d9ce66dd8c57c", @@ -1124,6 +1125,7 @@ "static/images/blog/solving-the-headaches-of-screenshot-automation-and-why-an-api-first-approach-works-better/cover.png": "9e34877fdbcc3439de5a858704c8d18ced08236ac8e3c46ba3bdba275f2b365d", "static/images/blog/sound-null-safety-for-your-dart-functions/cover.png": "73fb957b009391b97b6498acb6747cfb44f1ec21a3d465d7ba2716c807891fac", "static/images/blog/spacex-acquires-cursor-in-60-billion-ai-deal/cover.png": "885a59baa3e35ae43daa9d48db40533e7c11305411d9df6016da4240e9bf1fc3", + "static/images/blog/sql-explained-how-developers-query-databases/cover.png": "0f3d6d21772d3629b253cac2cb1b1f11364c8e18221e9f89c712be22e260b5d1", "static/images/blog/sql-vs-nosql/cover.png": "34afe294601659597c290ce1f2766eb2cc0b968775bc23dfe58dea3807339621", "static/images/blog/ssr-announcement.png": "c96acddc105a9d8dafaba838f3400766ab0f95a130eac7bc52f20daa325ef2c9", "static/images/blog/ssr-how-to-create-sites.png": "903b06eff29c30d05e51511902bb315b388324a69b11ab322e699727a6d00296", diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc new file mode 100644 index 0000000000..6ca0f959bf --- /dev/null +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -0,0 +1,125 @@ +--- +layout: post +title: "Managed Postgres vs. serverless databases: Which one should developers choose?" +description: Compare managed Postgres and serverless databases across scaling, pricing, performance, and when to choose each for your app. +date: 2026-07-20 +cover: /images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.avif +timeToRead: 5 +author: aishwari +category: comparisons +featured: false +unlisted: true +faqs: + - question: Is a serverless database cheaper than managed Postgres? + answer: A serverless database is usually cheaper for low-traffic, spiky, or unpredictable workloads because you pay based on usage. Managed Postgres can be cheaper for steady, high-volume workloads because the provisioned instance is used consistently. + - question: Do serverless databases have cold starts? + answer: Some serverless databases can have cold starts when compute scales to zero and needs to resume. This can add latency to the first query after an idle period, so it matters for latency-sensitive applications. + - question: Is serverless Postgres the same as managed Postgres? + answer: No. Serverless Postgres is still managed, but it uses automatic scaling and usage-based billing. Traditional managed Postgres runs as a provisioned, always-on instance with fixed capacity. + - question: Is managed Postgres better than a serverless database? + answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. +--- +# Managed Postgres vs. serverless databases: Which one should developers choose? + +**Choose managed Postgres when your workload is steady and you want full control over a proven relational engine. Choose a serverless database when your traffic is spiky or unpredictable and you want to pay only for what you use, scale automatically, and avoid capacity planning.** Both run [PostgreSQL](https://www.postgresql.org/) or a Postgres-compatible engine under the hood, so the real decision is about the operating model, not the query language. + +That distinction matters because picking the wrong model shows up later as a surprise bill, a scaling wall, or a migration you did not budget for. This guide breaks down managed Postgres and serverless databases across scaling, pricing, performance, and operations, then gives you concrete guidance on when to pick each. + +# What is a managed Postgres database? + +**A managed Postgres database is a PostgreSQL instance that a cloud provider hosts and maintains for you, while you still control its size, configuration, and connection limits.** You pick an instance class, the provider handles backups, patching, replication, and failover, and you pay for that provisioned capacity whether or not it is fully used. + +Services like [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/), [Google Cloud SQL](https://cloud.google.com/sql), and Azure Database for PostgreSQL are the common examples. You get a real Postgres server with a fixed amount of CPU, memory, and storage that runs continuously. + +The model is predictable. You know exactly how much compute you have, connection pooling behaves the way you expect, and there are no cold starts. The trade-off is that you provision for peak load, so capacity sits idle during quiet periods and you still pay for it. + +# What is a serverless database? + +**A serverless database separates storage from compute and scales that compute automatically based on demand, often down to zero when idle, and bills you for actual usage rather than reserved capacity.** You do not choose an instance size. The platform adds and removes resources for you as queries arrive. + +[Amazon Aurora Serverless](https://aws.amazon.com/rds/aurora/serverless/) and [Neon](https://neon.tech/) are well-known Postgres-compatible examples. If you are new to the broader model, our guide on [what serverless means](/blog/post/what-is-serverless-an-expert-guide-for-developers) covers the fundamentals of event-driven, pay-per-use infrastructure. + +The appeal is that you stop thinking about capacity. Traffic doubles overnight and the database scales without a manual resize. Traffic drops to nothing and your bill follows. The trade-off is less direct control and, in some implementations, a cold start when the compute layer has scaled to zero and needs to spin back up. + +# Managed Postgres vs. serverless databases: the key differences + +Both options can run identical SQL. The differences live in how they scale, how they charge, how they perform under load, and how much operational work they push back to you. + +## Scaling + +**Managed Postgres scales vertically and manually.** When you outgrow an instance, you resize it, which usually means a maintenance window or a brief failover to a larger machine. You can add read replicas to spread read traffic, but write scaling and sharding take real engineering effort. + +**Serverless databases scale automatically and elastically.** The compute layer expands to absorb bursts and contracts when demand falls, with no manual resize. This is the single biggest reason teams reach for serverless: unpredictable workloads stop being a capacity-planning problem. + +If your load is steady and well understood, manual scaling is rarely a burden. If it swings wildly or you genuinely cannot predict it, automatic scaling earns its keep. + +## Pricing + +**Managed Postgres bills for provisioned capacity.** You pay for the instance around the clock, so a database sized for peak traffic costs the same at 3 a.m. as it does during your busiest hour. For steady, high-utilization workloads this is often the cheaper model because you are not paying a premium for elasticity. + +**Serverless databases bill for actual usage,** typically some combination of compute units consumed, storage, and data transfer. For spiky or low-average traffic this can be dramatically cheaper, since idle time costs little or nothing. For sustained high traffic, per-usage pricing can end up more expensive than a right-sized provisioned instance. + +The honest summary: serverless wins on variable and bursty workloads, provisioned wins on steady, predictable ones. Model your real traffic before assuming either is cheaper. + +## Performance and cold starts + +**Managed Postgres delivers consistent, predictable latency** because the server is always running and warm. There is no spin-up penalty, which matters for latency-sensitive applications where every request must be fast. + +**Serverless databases can introduce cold starts.** When compute has scaled to zero, the first query after an idle period waits for the layer to resume, adding latency to that request. Providers have narrowed this gap considerably, and many keep a warm floor available, but it remains a real consideration for workloads that cannot tolerate an occasional slow first request. + +Connection handling also differs. Traditional Postgres has a finite connection limit, and serverless application layers that open many short-lived connections can exhaust it. Serverless databases usually build in pooling to handle this, whereas with managed Postgres you often add a pooler like PgBouncer yourself. + +## Operational overhead + +**Managed Postgres removes most, but not all, of the operations work.** The provider handles patching, backups, and failover, but you still own capacity planning, connection pooling strategy, replica configuration, and deciding when to scale up. + +**Serverless databases push more of that to the platform.** Capacity planning largely disappears, and scaling decisions are automatic. You give up some low-level tuning knobs in exchange, which is usually a fair trade for teams that would rather ship features than manage infrastructure. + +# Managed Postgres vs. serverless databases at a glance + +| Aspect | Managed Postgres | Serverless database | +| ----------- | ----------------------------------------------- | -------------------------------------------- | +| Scaling | Manual, vertical, add replicas | Automatic, elastic, often to zero | +| Pricing | Provisioned capacity, billed continuously | Usage-based, pay for what runs | +| Latency | Consistent, always warm | Fast when warm, cold starts possible | +| Connections | You manage pooling | Pooling usually built in | +| Operations | Provider handles maintenance, you plan capacity | Platform handles scaling too | +| Best for | Steady, predictable, high-utilization workloads | Spiky, unpredictable, or low-average traffic | + +# When should you choose managed Postgres? + +Pick managed Postgres when your workload is steady and your access patterns are well understood. If your database runs at consistent utilization most of the day, provisioned pricing is usually cheaper and latency is predictable. + +It is also the stronger choice when you need fine-grained control, such as specific extensions, custom configuration, or a particular connection-pooling setup. And if you are latency-sensitive enough that an occasional cold start would hurt user experience, an always-warm instance removes that risk entirely. + +In short, managed Postgres rewards predictability. When you can size for your load and keep utilization high, you get a proven engine with no surprises. + +# When should you choose a serverless database? + +Pick a serverless database when your traffic is spiky, seasonal, or genuinely unpredictable. Development and staging environments, side projects, and early-stage products with uneven usage all benefit from scale-to-zero, because you stop paying for a database that mostly sits idle. + +It also fits teams that want to avoid capacity planning altogether. If you would rather not think about instance sizes and resize windows, letting the platform scale compute automatically frees up real engineering time. + +Just weigh the trade-offs honestly. If you know your workload will grow into steady, high-volume traffic, run the numbers, because usage-based pricing can cross over and become more expensive than a right-sized provisioned instance at scale. + +# Where a backend platform fits in + +Sometimes the real question is not which database engine to run, but how much of the surrounding backend you want to build yourself. Whichever storage model you choose, you still need authentication, file storage, serverless functions, and access control around your data. + +[Appwrite Databases](/docs/products/databases) takes an API-first approach: instead of managing connections and raw SQL, you interact with your data through APIs and SDKs, with permissions, queries, and realtime updates built in. It pairs the developer experience of a document model with the rest of a [backend as a service](/blog/post/backend-as-a-service), so auth, storage, and functions live alongside your data. + +That is a different trade-off from a bare database, and it is a fair one to name. A pure managed Postgres or serverless Postgres service gives you direct SQL access and maximum control over the engine. A backend platform trades some of that low-level control for speed of development and fewer moving parts to operate. If you are weighing relational against document models more broadly, our breakdown of [SQL vs NoSQL](/blog/post/sql-vs-nosql) and [document vs relational databases](/blog/post/document-vs-relational-databases-vibecoding) go deeper on that decision. + +# Getting started with Appwrite Databases + +The managed-versus-serverless choice comes down to your traffic shape. Steady and predictable favors provisioned managed Postgres. Spiky and unpredictable favors serverless. But if what you actually want is to ship an application without stitching a database together with auth, storage, and functions yourself, a managed backend removes that work entirely. + +[Appwrite Databases](/docs/products/databases) gives you a fully managed database with built-in permissions, queries, and realtime updates, alongside authentication, storage, and functions in one platform. You get automated backups and managed scaling on the [free plan](/pricing) as well as paid tiers, with no servers to provision. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/register) and give your next build a backend to grow on in minutes. + +## Resources + +* [Appwrite Databases documentation](/docs/products/databases) +* [What is serverless? An expert guide for developers](/blog/post/what-is-serverless-an-expert-guide-for-developers) +* [SQL vs NoSQL: Choosing the right database for your project](/blog/post/sql-vs-nosql) +* [Integrate SQL, NoSQL, Vector, Graph, or any database into your Appwrite project](/blog/post/integrate-sql-nosql-vector-graph-or-any-database-into-your-appwrite-project) +* [Join the Appwrite Discord](https://appwrite.io/discord) \ No newline at end of file diff --git a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc new file mode 100644 index 0000000000..508f5f69bf --- /dev/null +++ b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc @@ -0,0 +1,221 @@ +--- +layout: post +title: "SQL explained: How developers query databases" +description: Learn what SQL is, how queries work, and how developers use it to read, write, and manage data in relational databases. +date: 2026-07-20 +cover: /images/blog/sql-explained-how-developers-query-databases/cover.avif +timeToRead: 5 +author: aishwari +category: best-practices +featured: false +unlisted: true +faqs: + - question: What is SQL used for? + answer: SQL is used to read, write, update, and delete data in relational databases. Developers use SQL to query tables, filter records, join related data, create reports, and manage application data. + - question: What is a SQL query? + answer: A SQL query is an instruction sent to a database. It can ask the database to return data, insert new records, update existing records, delete rows, or summarize information using filters, joins, and aggregate functions. + - question: Do developers still need to learn SQL? + answer: Yes. Even if you use an ORM, backend platform, or Query API, SQL helps you understand how databases filter, sort, join, aggregate, and manage data. It gives you the mental model behind most application data workflows. + - question: What is the difference between SQL and NoSQL? + answer: SQL databases store data in structured tables with rows, columns, schemas, and relationships. NoSQL databases use more flexible models such as documents, key-value pairs, or graphs. SQL is usually better for relational data and transactions, while NoSQL can be better for flexible or rapidly changing data. + - question: Is SQL a programming language? + answer: SQL is a query language, not a general-purpose programming language like JavaScript or Python. It is designed specifically for working with relational databases and describing what data you want the database to return or change. +--- +Almost every application you use is backed by a database, and most of those databases speak the same language: SQL. If you have ever loaded a list of orders, filtered a product catalog, or looked up a user by email, a SQL query ran somewhere to make it happen. + +This guide explains what SQL is, how queries actually work, and how developers use SQL to read, write, and manage data in relational databases. No prior database experience required. + +# What is SQL? + +**SQL (Structured Query Language)** is the standard language for working with relational databases. You use it to ask a database questions ("give me every user who signed up this week") and to change what it stores ("mark this order as shipped"). + +SQL is declarative. You describe *what* data you want, not *how* to fetch it. The database engine figures out the most efficient way to find and return the results. That single idea is why SQL has stayed the industry standard for decades across databases like [PostgreSQL](https://www.postgresql.org/docs/), [MySQL](https://dev.mysql.com/doc/), [MariaDB](https://mariadb.org/documentation/), and [SQLite](https://www.sqlite.org/docs.html). + +# How relational databases store data + +Before you can query data, it helps to know how a relational database organizes it. Data lives in **tables**, and each table is a grid of **rows** and **columns**. + +* A **table** represents one type of thing, such as `users` or `orders`. +* A **column** defines a single attribute and its data type, such as `email` (text) or `created_at` (date). +* A **row** is one record, such as one specific user. + +Tables connect to each other through **keys**. A **primary key** uniquely identifies each row in a table, while a **foreign key** in one table points to the primary key of another. That relationship is what lets you link an order back to the user who placed it, and it is the foundation every SQL query builds on. + +# The four core SQL operations + +Almost everything you do in SQL falls into four operations, often called **CRUD**: Create, Read, Update, and Delete. + +* **`SELECT`** reads data from one or more tables. +* **`INSERT`** adds new rows. +* **`UPDATE`** changes existing rows. +* **`DELETE`** removes rows. + +`SELECT` is the one you will write most often, so it is worth understanding in detail. + +# How developers query databases with SELECT + +A SQL query reads like a sentence. To get every column for every user, you write: + +```sql +SELECT * FROM users; +``` + +The `*` means "all columns." In real applications you usually name only the columns you need, which is faster and clearer: + +```sql +SELECT email, name FROM users; +``` + +## Filtering rows with WHERE + +Most queries do not want every row. The `WHERE` clause filters results to only the rows that match a condition: + +```sql +SELECT email, name +FROM users +WHERE country = 'US'; +``` + +You can combine conditions with `AND` and `OR`, and use operators like `>`, `<`, `!=`, `LIKE` for partial text matches, and `IN` for a list of values: + +```sql +SELECT email, name +FROM users +WHERE country = 'US' + AND created_at > '2026-01-01'; +``` + +## Sorting and limiting results + +`ORDER BY` sorts the results, and `LIMIT` caps how many rows come back. Together they answer questions like "the 10 most recent signups": + +```sql +SELECT email, name +FROM users +ORDER BY created_at DESC +LIMIT 10; +``` + +`DESC` sorts in descending order (newest first), and `ASC` sorts ascending. Sorting and limiting are also the building blocks of pagination, which is how apps load data one page at a time instead of all at once. + +# Combining tables with JOINs + +The real power of SQL shows up when you pull data from multiple tables in a single query. This is what "relational" means in practice, and it is done with a **`JOIN`**. + +Say you have a `users` table and an `orders` table, where each order stores the `user_id` of the person who placed it. To list every order alongside the buyer's name, you join the two tables on that key: + +```sql +SELECT orders.id, orders.total, users.name +FROM orders +JOIN users ON orders.user_id = users.id; +``` + +The most common join types are: + +* **`INNER JOIN`**: returns only rows that have a match in both tables. +* **`LEFT JOIN`**: returns all rows from the left table, with matching data from the right where it exists. +* **`RIGHT JOIN`**: the reverse of a left join. + +Joins are one of the strongest reasons to reach for a relational database. If your data has clear relationships, SQL lets you traverse them efficiently in one query instead of stitching results together in application code. + +# Aggregating data with GROUP BY + +SQL can also summarize data, not just return raw rows. **Aggregate functions** like `COUNT`, `SUM`, `AVG`, `MIN`, and `MAX` compute a single value across many rows. + +To count how many orders each user has placed, you group the rows by user and count each group: + +```sql +SELECT user_id, COUNT(*) AS order_count +FROM orders +GROUP BY user_id; +``` + +`GROUP BY` collapses rows that share a value into a single result row, and the aggregate function runs over each group. Add a `HAVING` clause to filter those groups, for example to find only users with more than five orders. This is how dashboards, reports, and analytics screens get their numbers. + +# Writing and changing data + +Reading is only half of SQL. The other three CRUD operations change what the database stores. + +Add a new row with `INSERT`: + +```sql +INSERT INTO users (email, name, country) +VALUES ('ada@example.com', 'Ada', 'UK'); +``` + +Change existing rows with `UPDATE`, always paired with a `WHERE` clause so you do not accidentally update the whole table: + +```sql +UPDATE users +SET country = 'US' +WHERE email = 'ada@example.com'; +``` + +Remove rows with `DELETE`, again scoped with `WHERE`: + +```sql +DELETE FROM users +WHERE email = 'ada@example.com'; +``` + +A missing `WHERE` on an `UPDATE` or `DELETE` affects every row in the table. It is the most common way developers cause real damage in production, so treat those two statements with care. + +# How SQL keeps data correct: transactions and ACID + +When several changes must succeed or fail together, SQL uses **transactions**. A classic example is a money transfer: you subtract from one account and add to another, and it must never happen that one succeeds while the other fails. + +```sql +BEGIN; +UPDATE accounts SET balance = balance - 100 WHERE id = 1; +UPDATE accounts SET balance = balance + 100 WHERE id = 2; +COMMIT; +``` + +If anything goes wrong before `COMMIT`, you can `ROLLBACK` and the database behaves as if none of it happened. This behavior is guaranteed by **ACID** properties (Atomicity, Consistency, Isolation, Durability), which are a core reason SQL databases are trusted for financial, ordering, and other systems where correctness is non-negotiable. + +# SQL vs NoSQL: when SQL is the right choice + +SQL is not the only way to store data. **NoSQL** databases (such as document, key-value, and graph stores) trade the rigid table structure for flexibility and horizontal scale. + +SQL tends to be the better fit when: + +* Your data has clear relationships you need to query across. +* Your schema is stable and well understood. +* You need strong consistency and transactional guarantees. + +NoSQL tends to win when your data shape changes often or you need to scale writes across many servers. For a deeper breakdown, see our guide on [SQL vs NoSQL](/blog/post/sql-vs-nosql) and how to think about [document vs relational databases](/blog/post/document-vs-relational-databases-vibecoding). + +# Querying data without writing raw SQL + +Here is a practical point many tutorials skip: you do not always write raw SQL by hand. Most applications talk to their database through a library, ORM, or backend platform that generates the SQL for you. You still think in the same terms of filtering, sorting, joining, and paginating, but you express them in your programming language. + +[Appwrite Databases](/docs/products/databases) is a good example. It gives you a structured [Query API](/docs/products/databases/queries) that maps directly onto the SQL concepts in this post. Filtering with `WHERE` becomes `Query.equal` and `Query.greaterThan`, sorting with `ORDER BY` becomes `Query.orderDesc`, and `LIMIT` becomes `Query.limit`, all with type safety and built-in pagination. + +```js +const result = await tablesDB.listRows({ + databaseId: "", + tableId: "users", + queries: [ + Query.equal("country", ["US"]), + Query.greaterThan("created_at", "2026-01-01"), + Query.orderDesc("created_at"), + Query.limit(10), + ], +}); +``` + +That query does exactly what the SQL `SELECT ... WHERE ... ORDER BY ... LIMIT` earlier in this post does. You get the querying model SQL made standard, plus permissions, realtime updates, and pagination handled for you. And because Appwrite can run on a SQL engine like MariaDB under the hood, you are not locked out of raw SQL when you need it. See how to [integrate SQL, NoSQL, and other databases into your project](/blog/post/integrate-sql-nosql-vector-graph-or-any-database-into-your-appwrite-project) for more. + +# Start querying your data with Appwrite Databases + +Understanding SQL gives you a mental model that applies to nearly every database you will ever touch: describe the data you want, and let the engine do the work. Whether you write raw queries or use a Query API, the core ideas of filtering, joining, aggregating, and transactions stay the same. + +If you want that querying power without managing a database server yourself, [Appwrite Databases](/docs/products/databases) gives you filtering, sorting, and pagination through a clean [Query API](/docs/products/databases/queries), backed by a relational engine and wrapped in permissions and realtime. It is a fast way to put everything in this post into practice. + +## Resources + +* [Appwrite Databases documentation](/docs/products/databases) +* [Appwrite Query API: filtering, sorting, and pagination](/blog/post/appwrite-query-api) +* [SQL vs NoSQL: Choosing the right database for your project](/blog/post/sql-vs-nosql) +* [Integrate SQL, NoSQL, Vector, Graph, or any database into your Appwrite project](/blog/post/integrate-sql-nosql-vector-graph-or-any-database-into-your-appwrite-project) +* Join the [Appwrite Discord community](https://appwrite.io/discord) to ask questions and share what you build. \ No newline at end of file diff --git a/static/images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.avif b/static/images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.avif new file mode 100644 index 0000000000000000000000000000000000000000..41106cb1d291146f15c3f451132d4325a9f87d7d GIT binary patch literal 8427 zcmZv>Wl&vP6D_*2Y~0;FI0Sch2<}eMjXS~JU4vV22@)*0+s55pg1g)0oKxR>Kkn@x zvqz8aQFHdJwW?OF1^@tr<}Mx%#%>^Uz=zp_%)k7DZ9&E#F@%GynTzp1{D+ZQn%X%1 z2LS*FkcrFx@c%rr1IWep-vHucWe3^VoBR`r3j-hl|1bcEYN>t|I z$&T07!OY^{MU>YBWa7Z3lzE1Yj z*L*2%AHZDP))m+0%b|%9AeV#C_Cd0ypd%k=ctu&?CNvUpow1k;s2^smojyZ@ehfK5yDK`8zQvKHVyfsb11aa5_Ic`_`fFEsE~49Aj1;QxyoG2S zEjVaK%giLhy+KfR-OC%JL9%>y8A>8rq|xk&KNlpGH^2|P%CVh!#-A#|Bsvq*qZwvFIc8nGaSDM;rJAYyl zjss^L_akzO@wE}{5Mu!6xd@x$c38LiTj!&B3y@z>RQ9#E)#qevM&rHR%>)=YmDSwcdZ%;xMd>ONvNrr;TEII3rK%q{`>q- z1FjRORXjNMWsy|uP~lV*+a0C{iP7CARDE6X>e}~lITboM3C?rCDs8pW;Sy~QgZcR5 zTv-$0&bR|AXB4~gIc+;%hpRDBTdvHYz>@wL^Hn*7xl8f*HV{OyQm3cab2L@BfRQ}b zAz=K5eqw{>cv|6p%C9aIL()({u9kHH1t0Iljtrq*(SWxReH%H#% z#HsOa2?be}RZM7@3aLw156LqS@vURVW4&{5T%Q@F&4bL5rOWACf^f9$`Lu6+8qQy; z1i>BP?LBCTja=v&WoZq{f|((GgE^BT=bVe(vI-(+chF1n*rb8#G(?1_AomFnKQI8zvEs>^+VfmUB835W`i)Cd*G0Md8XBRc7D@-T&&yW z<uf!d>-MtOgfvSp9Tf1xwQReb^e0I`pBL?Q!cJ{;2QXO?oqU@#&d`H4 z-aSnaZepZ|^=P%y8ME%sLe!$XXYIu_LX=N;I6$qO0lK@SGNk zBQYkn3TzV8O$XS>xOfuztlK2Yx|7bHg6WOcGekF(p#;(A`uUKj(QK^s(4lpRp%)}X zRQgMOv`w0PIvc)9i&2TxC#yG!?4VpfrQr||3d9YD(^gw1nG`ZhOS!C&k0ISql(@AQ z?z_V8vwt(_73D=yyUKcfr3~bP%qhFePTT41AYXw$iLD{L;*g1Arp{O1 z$ge5rq1JG{Yr%){2&LR>+%lcspZDAmBmO(b@b{@8scp4>AW?6bU2sNj-v)`fS)aO6 zmo0mgXje4^Xxwa*5ujG5{j(?jcib!}9kl)uutW})oWqFFr zFLD_A@kD0iw$t(#8Js(`)QVT8;Aw0j920YBONw(_g0Rgu|A~l7gJ^$0N~@Op+T1Jt zad90^demM&A3@co2%mrv^!Rw_+OLd81NrlGGL}dKsYUXv>FHdkUUr%Y=8Ppd99WU^#NvW@WDRP@OUjfzWQws#yA_VJF0Y=s0 zo^3>{zgY!;E#}4LeH0r)U?^$wJ1#nQF=9+?idhqtu>1^tOjv0Cp_`Tc_>U6IL#^_f z?vdJsxE?@bImM51GHUdCV}?>Fqt)OaXVV8R4KowC_OGgQH&7OmrR|t`MoB>OMKwaB3?vL?ED`sZ?xT#->2exo9L)BRK}^tV*2%E7`j2zx@bSEZ zpPD{phW(HIq7HU~bnwGQ7J4eN-%?mH8VWXe1D+~XEJ!Rsi=59KL6S0v5*mnsUhF2` zcLiJz{Si7iTfwIbgJ3&d!DM0Y5gxkE(%MJ@Z`CSkQV zkC6nh5`~voj*LJdW@b;epBUi08IAtD1j1- zIjW$V2vC**z18gup(3MXV1;+-JEpojRD24ZRl|t<8{k1mFGS2-cWSUYt+}aA>UMLr z%B?JEam3M=H_xpoem6kXBIFy5UVW@7oH+#Xee%=?J( z1X~t&r@p~L`Dg(GLk%{Z%ZYbqFJux?ZV^)#yb>$kSRNEsNfK*$%5MQIZ5ATctJGx! z@8ZpcBm;Du&CNcnc$A@{$+mIA&-pvd{`FSOjfZ|vcCW0Z@BxR|s4R{Y{lwWSvCq^4cSl%>;CWPgdJp zIB~+*0i3JwM=W0K*REF;mk8g?3{X*5XhHgJ z+9(+`Y37U!&R;G0H`uZpg{Ptn?Z^dYh?+=X*1cAUgrF5ordYE08jr)gc~4eLP4$zE zuznl5KhO=)H#wb_A)OoA+HD15MNsa!N4H;M8cz&i=-hb-ZBOgM4dC44Y1O1Bnm+y2EzzPZ($YHZ?~uC!v=*h~&mZMhT-5p`snq9DHFiWUW zc#tUy&%#39R2j$mX*9qWif@$>36p@A6z6Hge82r-C*XiaBN3^n!|!|*Zryr`Aym<= z7Tyzx5yb6&ge`O+ZYwOSO*FO(TmP^95Y}^^n&1?hL~c>%;eosKsRGHg42Qsn?aBy` zZ#c{-CJmGpP|Es|aEl2!>p@-}*b%WVtc)B|)U2Zh4f%f>)OnGqtSi)RNVxY^CdlPu zR@z9|NwBj$uQzFm@4UT&7JpnAj)FO?6DB_=^H-_%Do@WHd)73SnLSZ`Wm=23#H=&a zAZ7DQ8+jTQC{5FC5Loxv?@=u9`6~xeNqm?35}3g|4jvL$+L$!TKB7J?8ZOwmw&0i& zsHk)orrap_E5luseROLdd$;WSn2mKO8SD^UEVSDvhl4)x`+YL&$|@>q%&Y(=8|)%F zCVp0pKWdw&9R4a#1zDXG?29OTcrbm`3xLe(8Pm?3$lr1W+aU_2yaj?+ z!%gin?#&CCp+;<-%a$nNsj|?n#|&4#rC;yzO67nSDUBHWDFXoxKSnb9IS6I8qqkwC zPu;UPbq9ZHrT1W852+*Ir=vu=n8U2UDtB>Twf@h}$mUoHLp>G_Q~1&WrHfeK;~m!^ zfUH9Rcl)bUe>a9v?CPf!L0`J%4N4F}u;J?(;~nh8+KiQd{xaQ+Vg-kNIt#Kt8aMvPjyDGS4 zP@EzpTELpmA~~OA>3wa@2Az_7cV)lOdu&3(fF zi`5)=q0y#hb#y=uRNMnN^Ap)1m0a3i72N&=W%;|5?$s;fWdhK60SZ2DhvXd|I>APt zb?Ne*MS;=5e7)CN6%hP%iazAUaLZKN>>p(SdG1jZauvnGyC1yyrETHT8)Vmi+cfZV zhylDIKM1QsC>%B|FmzrLL)*F=7=5wlujTvo4r_+KHVqc*F4uOK+GCe|%*$<2z;Vv0 z$%F2OWAnlU3ssHjRO9-MhvZXx1kNioUvMytlP}a|1l>zXJzd&Nhg3*ck85T(L5q}z zKxYIWhgAz<8Arn{-u4q*+=!yGq=azi!|dfS$>kCdg(gxl!EE?N2oqS8>t2)(`)tXE z+G|76Q*U^{MiI!wc{(E}Fx$o!%LW{no;(^Y7wOrD@R9zxZM72vCeWlb9+^mdlysKd3 zLp+4A#Xdi}_zRvC0X6Xjw)2Qh*){?nuF6=dOQ@*aCJvdp2;u2uZnr%apM}~v*d&Ws zyT!7Bk+{z>e(&LH|3z}B2T8(YayG%=zOgc$9iqitEYfE_WV&j;_GN)k7q|sjG8~HX zHl8hnj;#QfXP{7Ylj9Kk&YXkr^;Se8R58wOjH_Z^}~i+gbLP!*_GNAfw+0=6V*BSowW-ssi`hI&Bog znfEde?zC{kEX!kOk-6`t`%e1{$^?e68jxfXv5Tw5ii#^pLf%9rq7mbjfanC>#Pu&HEA`1Ir)L}?dCljz08Da#qtnHOzVphS*yRF$ zU!~0HhGHa^7fEoWK**^*zanl57*BzBkV{?Ajj%@piRz zg$BuP$j~Zqr8%7hQH5$Wz}6o2`e>ZtV_ZH4Biy$SzVG zPJxIxi2l}lvSdwYp(1-fJ264i81LV~k!Q>l*A;QlmJVE_i`OW-)jKE|vo_MZrU08R zBNd+nZQ*g4w1uE?5!a53P-87e!;Br4R?lQ$!^h4`9dQU8#eFa99~@JjB3Yx74&A?$XkrKfl9(63@PJ8r6l}B?sLBaxv5NJ z)$~ID+z#-2otHH)QG?IR*D~!+jMdd=0Uz}G7t$-^0~tM4FiDuosWaP(tZJ|1BH6x7 zn8(aaGMV5{qwVHJx$ut=O)#0NTJFihoH$*W8#(}7AZl*Dhj4qT;*BkK&v$4HjLz__G^qj zW3vH*s~aYuyTN}Ht#^4X+Am|GbD)B+`K!CK-8P|d@Yorw(n$aVmJ##*J$8(SW8aLit?9%8Yaw^sdb>=JLI{qb>unv$l+lo-vAOn_6CsDU ziy$n9f@k_L+94{^?ytV!bcPfS zO1Wu#D{SA>qm4;>lrPIY9IXnFcyx}4)H%k$Tim;-gZhLU>7*=w+0=U7f{?^8K0qgk zH<}rTRne1YScS9^w4;Z_>>7xu`88~)X1P0Kr&DbC1>$f@SC@4jiBP1c-f7RJn(~fS zt!Hs(7WjHHR5K-YNu8_j-MPBJ?-%8mA8J5-M6b{kg89tJU8P2oOC(Oqa)V@%;dae%2$cwjmo`$Og;VQ<3PNbAK$Uc7*~SD z3RMY+kEYr(;q4HUz_Pt*AZr&z+OR;eOr;DQ_J+?^9xEH5Zb_6BWkmn~{jiswX_^R$ z34D;uT~YIx-0Q*nd*XTyc;Gl;%5u1vK_6zu<+&sIT->0iX2aXa_1OtrkBd=!b7{YdDzh0w~<@+HAp`d{WX>nEZj^uvCnm_EkaXicR#pH1-?aPl;ok? zpp(ar;cZ#zr!`?iPe`59-XTUc51(&GNnyPL9+AAMP?Cn7G>??rwhSKB1+Z503#ydr zLN_Yz1mztWhwe1o>=H&6sK}=4%#ZMtTM}&?wqDeuQOPx+(dlb3#Q%G^2q<-gl6(+OQ zwjZi#8|!>CxUkok$C7Sr-ixy?uA`)pLkiwqDZs5AsNhi&h@B#$*g~9O4b4W5*jEn= z6YvsBw_KR{)|%0fizLNP)TrX@lJY*EZ>wV6pjVI6(^}zK9PEjX+0Im7Oy}GfYpW)8 z%bJ;=ErzxQ{WUtK~a&3LDn5IGtU)?b;u+u6OTN9{hvt0{SAbDar!{(-q zbWJv1%e4^8wjZ{z^T3#P4 z*T8JaT`-(xqd}xgf)!zWt^y#F0Xw5Hr!d3wu$FiXA^wv69;hdS5!DD*>XLGkWmR+O zrPQ~KhZgn*V!xrAM@Wz3nl40xtH}P9^{VGJKfW?2g4li_POyByR z_;X*sEA9!tbt|AvnRVAg<5giwpMWg(R99I^oR$3l!8;>z$heI^FM|)S)}iRl}y|T|2p4iJenBHsM)%QZ8WvBKiK8 zQ%zz=L`{q%sPpo)mrsjdy)VE0HcdOSABT0mpVS^cs@KjJ-wl=@+KLeksju|DurWAMs5GA?>lIclLk7jeX>!ikn$xw}S z9ci2=B0y&sEH)JHH=gkRC-r5bR+IF-n^>%|e2)sCb3BlIP7naR7TZANIt6GmuaW^* zza?;JtJ#<1Lqb+A_yqfpI68-Vm52R6Lg;jlda?bca_c0YkYxZj($RW*7G6?W8^flX z>nTJ2j#_LRISeyPaJqE`IOwhoh?@mG)2p5bf`a!aF8e|gmLo1`taUPKGu`+D;U_L2r9u1T0HE$F3) z&paq`#r}r>AgWo-v4nlya7A$?_XzqZp(=5+HNgG>wSs0YpqJH)?${Yy`&_bx5z%eTxRYG3EvE2f1VC< zK@zwl*2$M~Dwy-?GmbtV1Em^f@CS^U3Sa0e4KW5&H`Lb=V3`D$P22nHu+Fw-xjf!tR)Uf?+wR0NFZ6SLzcL`j{lH|v)2W*$vo63mwcxCqX{qECt3)P9SW z8V4lA-AX7>%%Gy?LQT8p(GJRU%l)Enp3I(f;$X;Mz3yW26r5@&+PobiYCxypM_aRCT{b6vP-n(*E!r~$^9N-DyOI6rK!51+N?q_dKbAC(*OU3fNOrQpZCU@{el0L&5-`z J;J*@<{{!mc1k3;c literal 0 HcmV?d00001 diff --git a/static/images/blog/sql-explained-how-developers-query-databases/cover.avif b/static/images/blog/sql-explained-how-developers-query-databases/cover.avif new file mode 100644 index 0000000000000000000000000000000000000000..c4d1eae7e1a9c803ee12d96e7a0f48faa93f9cc1 GIT binary patch literal 6457 zcmZvAWl&vBu?iSqP5ai$*EVx_H-~{*J?(Xic!9DmTNqzNR)xG^= zdiCmFwRg|d{Fnv+0EFgF?qDMqkU8MZY(VC0f3OY6=q-i-+n6~S{o&t?%+l1_;U5G5 zz#tQ+|L}hv84Pl=`5QpIt(+ihJCi?=m@ohm@P`3FB>eLL0FKlf_hz^&|1ki)w~!YE zvi?Q?Hp>%SZH)+A1ujj53nI^g|#J}Wb?qb^8%BvSTzW=U~I008Fg1fUSL zR-=g~ufg2KHC@4#`rPcAppMNZQ_3*p^Cc`c>TSk)>giuV6J1qBBr7`i@WyuV& z6%`@vU!XRo6H%>tsPj#26@UBhOe`Fo*3c9oBeU|&u{2xu`XjoM+18ep8P@9@HBf>P zQI7KV7=dG-K9!oVeRIGWaj#M`V1SR`zF)PzxXQDNK799Z`7P-b)|WYZ&$3}lSZ!~~ zpY0=RsfBEof~UCx%oVwWeKqAOeOm32L$sk!K3Ny}i9;XB`y*&liFq%s`mPG21Nw|@-{t0v*ChOJ@6S1tfN4c89OE1BG% zq9a?;iE3A{PbQgSgyUiRyWWRRgtn|Yac_s;Ck?^!Xo|=_)d(bZ-wEvwc6?Jo{Z24ECIt{lqRhHdHQ;T!sgIO^Vf(ztg|+cH zRE=UDVIDK%8bS6eC8ELw=}Y*r`NCC7dyQ%M6^h5w&)a$(+snBW?Rus@$5uGKMbw?G z%-#KE?>PVX;bU}R>8$;Ieqno3s0W)yhep?icP{0XGpAbkg0xSsQ3T0dcU&g@d&B9S!B)Jf!_ zEn8YX1ph9R=|C!m$TWf!qyL)k;tmI=2rEOsp6A0jq$WH;oH3QIGJwle{LX6S(M3}I2Ne#meQLWhc5ARzqa%h66#!EA<4 zA-R_r3aG|P5Qh90pK6w8e?<0>XH!Fm%PT@TH8~;CBgv^zi2gS{HK*mS$l`z%aAxti z^Ie%eJ_6W`vU{w|Jaygts+mOT3UU9w1atIZ{h5b=Wn9tEK?YAHeq3>pLb)oKLsMcP zbTO~D`G>eN|MpE6wUa40TpnHVk-jEvrfXNqjyx$3J_armT7}V^uGKFbjQ}8v(|Ef% za_WWb)YI8f3Z1y;VOy<_bXHr-CJ}=bB>@|qMB&d#m+qFGum1XYWyNutYhLo*cU)+tO(|+UZ-&3lHHyWYpNjK_&zt(ifaDNUsu=VAq?;&}@y2(yn0< zdEHk!_cWu;*ynnDcbjFg;OqW1@Nu7_ozv~MI~Oe_26q3%0wjoIaLI82Q8wVUy;=Y2 zr*BQ2O_lDWZ3;M(Xgsh{Bp58C0zVWRK#)K(WI7bk@1GkJXQJkdhL*tR|wxMbWS^ zD9dzC^6`q+S29fUPrXzVVp($84Z|AO*m-)l!yZM6)#bEl?a6uL>8Q^%7pK@_On&-x zs?t0>dpvllFORHZ%Ka&}LwinB5{J!Ie0UeYXDjI&DGJ{RE7c*-L-l2Zq#D6BlwZ9gENE5N0{@79_0&6j?vnPq3&tNuLdiunAzyyw1`+69A zBJ4~554;H*r|D`VgxpKiCM&7j ziT4Tl@X$GWduhbQk4m@*my>Q-uh9Pb)v55z^aV?R^wpiZ1UfoNJUV=qpz0}wi^ks* zlsLa$U0>`K=BzYLMA((Z8C2W(!+NfIis_u~RE*WdX<0un%0fpy%v=|k}l?> z4ewg{cp;advNck7cb;S?TN&sLWZVlS*(!}V;<|hBGOyvwo_V-1&j*f0xynLD=WCEh zM+z>g^L!(p!W@&lB~`+uFH?(^m3zlN7*HbPOnQmuu5BZMd);*=I180^r!6c1PhxYV zKk|FWI;{rzj6u*4lV6O%oIUS8DCMpZ-veEeSV(ov%3jMDbZ9@3EI*cr zY$n>xbs+p1G@vSE&uO#Kgn7qDAeG8wQ`^ zu7GD!GJLm@I9K6nnID-veQMniB((N)_iea<&LWDz5gL)@5#}W?Hi$Vtwf5gDq3#Du z+2LOkGJhWHj+hFz9c)&8PVEqpO%z~dK=OE&3&cl_{J`hUdD7ZgZjp!~KN)Y|pfmaNuU^KY8Gc=8pm;ThbS9t{MKz`ia&(@BM_P)QzASPVJR6dg4j7s(5>y zAv@9;w|QKf8GVM3CZZepM#M4U3*f^l%4Cej-696h!=%I3fJ5ikns%(!v&*%!hP#O( zDoKikTQF4= z1Jk%3Cm}i#enRe^OrNNjN6l1tBy$nhwINvzRG$SA(I$5A41_!fHy!t#+KOCJc zjA8fk6{9|Nj?8OeV#MSj&2>f>Vbv1aykkI-5-C*O#zciEj|ok?l$!i z=s-i#SOa)6d?Oq^nzGYTB-O3|96c3{Ua{8MLb{Wkl6qngYP#WcySe7#P+>7k>~sRh z{sPtM^MF-N&iT}O@O!-<`H)J0dml3QhdSik=>9DJ1;rDpjVxO$$W>DR4-1HA;+&x1eG?!A9t`R%4`sUwtJ0t)xul13|~{g z2&w(tih)YfByds7xx$xvQx`Q*6tnXP!M`@XSGnvBHCw{*vg7T2=`H;DUC2C)`EY1p zkp4ERj(7%{6E5tcI2b_WG0%xK^)e!++rtC9qk$G47Q)F5%aZ_}5Ha=^@TS`0*6XR9 z2HSZFxqcqLNn`$y0;(m*@{Tuc^*-#bz$|=5;#;0bIh49PYsRbGI*#}5A2ZF;-tV}h z*yo_`>Pw*=U*4;xQMgVRrHl2p`cQZ-RvVcWf1e$*irNnB*r7c=z1sU^JT536fdGip zM{~2Qd-sw0a1eNIKyz7Np+sb^DDtW*eza!1x->`4w?GiT<0On9KV#5NL`qrkVkucS z4D+&3Nbf1{t^Ct=r_?16desuh5--;nrntU)(W?zAxmeCe_(swq++zK!Xs}aAI}%5d zAgBr~BHj_@I}%k)czQ?<9}X$Eu2S10RkZUmFfgHB*DG6N%%5wp!>>R$OckI@DB%E` zx%SeQfuW}tUu-)1iq9H%+tX!)W-(|sF6qDk1KCkgJ{fe)8R5k8G!S{W)DaPeYfe*g z3r8aIyZ$LcCnzGf^z3HQqUhl2RFJNl7YG8+B8eT_j;CYq`QJgI{JBnKplt8 zR|dTxBekEGQwV1nd=dcj`2wkeU8qZ!e+r1n=7Cjy>1=b})Xxl$6iSb5o=8Pu#<=m0 zKF=&AyDHg1zdUOaQ%K@@VE9bNra#kIrI zV~#+NbFH*HSO>N90tS=$_!~rl=5m-87O!3}k@$9pE^V2w` zKxC_9?X-$j<jNu0PoslZ!0^ z+tq|-W3S=Z)CZA6=H5R}&Ax04TH)yIgApebpG%H%ZbIWHo0r(WBQH2Fb9ij`!(3y$ zdTy7!sk62C4WHjn`y{Q&(NsI6O6Q;1j;X(UkSxo4Dq}LZl-`QZsWHCpM<{j+SL&@; zY3PRVHMg{krqWH72J=>^-Jg7h|B(+!fHnP_qTIReYj=2%3oao+qjrque#p>;QpB z;TEDhmlH!d*OjZ#+AEJvDmkCDCrdW-?C4uKTKZV$ffEmErUbQA&j82l%WOmRuLYm! zo)jyW((Sufao(;Ras1n~WAB%0WQF@R`6ObetFGZivID0p%$g;3A-{VvAQsfoQ951M zOt8e1xt6Qhenm@ZsYOhj4_A_dsRgjQ(>y>gts+HB3Nq_QYLZ55`J7(`b;B;9r z&d}^MtIcDHqh_5Mp5(aK^!%GZbXFz!ma zzuz3B$zSTD<=qHTSc{4Zl-C93^XS`XV5Ns%rlR6czUSjTKtCIgO1dgA-qvWTEqpG8 zEd3NS+SqP49pXfnvDoV~paYiNo#uCQkPGE`w`CXqbb5ZM3s%Sm`H)F?xJWZ{)B;jP!ECzr-!WA9d5&WP@!{M>hV-7=VMr zWxpN=8*_05W9C&RX}qxa8IMYRbe&owR7BiG5y@>fJ3gYmg>mCyUn`|g@Tsnsi;%vw zDhNXyJJ0{#0a3r(w&a~fN>c@VS z=w{jJ7%HJSw7lA1s)X5;J!d>gM}tU_7*>S&a_I+|0N5UhJb@XUgR{hA4D^-gbw@q! z53NA3QkRgOC@PyxDWtw(I;`CYsE|+Uw#b|sr6t#cw`Y;(;Rx$a$T4YJP4iwYDNq@~ z&V$hGKdkjt)N4%;%+%TV`BIE}t6E8|ep{GWvo&T)TE3IQax~wS(i~u!HSd~yQ1o5U z`#!uGNd54d_CANcTA{5Up&1EUe+$^l?jFbFQqP-S!lssGkF0mihwqWwn#pUN4#{81 zmFjgRG7V^j71!5&a?!bMnieQ8QMXnTXFEDJ1a+w7V_IqrdBF&=SM7C8Y$n zyenL{XwnyXsh0-xEMJ;o?MLb;*|`FaDU^8DK7X2Rc}h2A2vQC~TPd=P%*1e#y1?+T z8`MmT1KqIl4Wji$Rq`#BGd_<6Fs&u!(7@bQo81gzMLmMfbXygbr}o+VT<1FzSH8pu zgOKt}F-w?tfeB?tezzMhHHk&>)W>{MVGwT6!L}1&rAwHH@hgsNvL>koYl-MefUY|N zjci0;BNZit-PWH11R%ATJrXPpmd~A+D2Zu19r|>W<^0J;Fdc({-`PLxG1OaDqFp1Y z6NskhIx-TOXsSQLx3c&3SQE=GSu1`@j^z}Asa_w8yKFb5S!kF#3(8<(mxM3eIi7%H z-|E(pt;z`yi)r!O+4EB>oMG9)^s##lg{zWSNI(PcQyUmL-c+21D#w+;?zE={v_1Tw z@lWFscc{+kw6BHzQ2tH#$hr@EzYSgt?Kuh?3o})IF83m0NR@o{xYoBX^tP+8;;Lh_ z(ld)Qc%qe`@qimqP4O`CI~@uI*GI#T`7PfU(tE_id}lkr5WkrkMNZU8MTB$OObwG* zg%ufkoST9IYI@}KIf;LkpZ2&cA##3lX(C$diMv^CR%-q%YI)L4O5$;Y{KcEc%r!RF zSU)QFq@M?pz!kAtu83Q~9H_@M@^}O*Sv!s2XT+TM#87I0(Vw`kzJ>tD%(N^XP1#%M zi2M}gCJ%|+BDsbBZOFuMm_0r-w&R53XV!YK7*l&1Z%hGxxoiK?wO#poy5C$uh(q$- zd-)dA$MbV=2W=E`w@m;J%@*C$5}0^(3=jnO@IM=RxA?&#Eh43l3lyqrLQBAfK8 zVU)KR#r{Uo}1c95xx=*tM852*0QCA0w079uPhhu3Yi;vNRl)XHh4sg zi<$XQd1#MaJbmz?)8J5pHNDg_v>`dUWQFl3#+sobJdTM6Qvtqf%{}DJ*l|UeL877z zAYp!b+v+FP!!aMjP{(3XTjlK}b?Ls#c2V5B8_u-PEIPl^&}*)T=REY8p`sld%9;_h z1h!5L-{$DBcz@^US?o$gfVbhl5&#aJ4`cEQVd}#7|3a{6}V=TU~|H`IG|2Ozo G!umfJwIH4V literal 0 HcmV?d00001 From 2b1d3d77dbface149913f113f2c4c3f0cd4d1dee Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Mon, 20 Jul 2026 17:06:56 +0530 Subject: [PATCH 02/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 6ca0f959bf..81e21d53db 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -41,7 +41,7 @@ The model is predictable. You know exactly how much compute you have, connection The appeal is that you stop thinking about capacity. Traffic doubles overnight and the database scales without a manual resize. Traffic drops to nothing and your bill follows. The trade-off is less direct control and, in some implementations, a cold start when the compute layer has scaled to zero and needs to spin back up. -# Managed Postgres vs. serverless databases: the key differences +# Managed Postgres vs. serverless databases: The key differences Both options can run identical SQL. The differences live in how they scale, how they charge, how they perform under load, and how much operational work they push back to you. From b695a19672f6e2fc74115bcffbce4f4176094914 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Mon, 20 Jul 2026 17:07:18 +0530 Subject: [PATCH 03/18] Apply suggestion from @aishwaripahwa12 --- .../sql-explained-how-developers-query-databases/+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc index 508f5f69bf..adba3148ee 100644 --- a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc +++ b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc @@ -173,7 +173,7 @@ COMMIT; If anything goes wrong before `COMMIT`, you can `ROLLBACK` and the database behaves as if none of it happened. This behavior is guaranteed by **ACID** properties (Atomicity, Consistency, Isolation, Durability), which are a core reason SQL databases are trusted for financial, ordering, and other systems where correctness is non-negotiable. -# SQL vs NoSQL: when SQL is the right choice +# SQL vs NoSQL: When SQL is the right choice SQL is not the only way to store data. **NoSQL** databases (such as document, key-value, and graph stores) trade the rigid table structure for flexibility and horizontal scale. From 97c9f3baece49c1888dac059a129d3559bfe67af Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Mon, 20 Jul 2026 17:28:52 +0530 Subject: [PATCH 04/18] Apply suggestion from @aishwaripahwa12 --- .../sql-explained-how-developers-query-databases/+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc index adba3148ee..6a28b10acd 100644 --- a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc +++ b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc @@ -160,7 +160,7 @@ WHERE email = 'ada@example.com'; A missing `WHERE` on an `UPDATE` or `DELETE` affects every row in the table. It is the most common way developers cause real damage in production, so treat those two statements with care. -# How SQL keeps data correct: transactions and ACID +# How SQL keeps data correct: Transactions and ACID When several changes must succeed or fail together, SQL uses **transactions**. A classic example is a money transfer: you subtract from one account and add to another, and it must never happen that one succeeds while the other fails. From 7a80951e37cb0f87f1781e3bc988132454cebebd Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Mon, 20 Jul 2026 17:39:26 +0530 Subject: [PATCH 05/18] Apply suggestion from @aishwaripahwa12 --- .../sql-explained-how-developers-query-databases/+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc index 6a28b10acd..d2fdd2cc55 100644 --- a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc +++ b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc @@ -132,7 +132,7 @@ GROUP BY user_id; `GROUP BY` collapses rows that share a value into a single result row, and the aggregate function runs over each group. Add a `HAVING` clause to filter those groups, for example to find only users with more than five orders. This is how dashboards, reports, and analytics screens get their numbers. -# Writing and changing data +# How to write and modify data with SQL Reading is only half of SQL. The other three CRUD operations change what the database stores. From f4b1a16443705e4542cced6ec5548df3122a288b Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Mon, 20 Jul 2026 17:39:36 +0530 Subject: [PATCH 06/18] Apply suggestion from @aishwaripahwa12 --- .../sql-explained-how-developers-query-databases/+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc index d2fdd2cc55..17430c5a48 100644 --- a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc +++ b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc @@ -98,7 +98,7 @@ LIMIT 10; `DESC` sorts in descending order (newest first), and `ASC` sorts ascending. Sorting and limiting are also the building blocks of pagination, which is how apps load data one page at a time instead of all at once. -# Combining tables with JOINs +# How to combine SQL tables with JOINs The real power of SQL shows up when you pull data from multiple tables in a single query. This is what "relational" means in practice, and it is done with a **`JOIN`**. From ab1cda8009a69752787e45a7c64623f43ef5e031 Mon Sep 17 00:00:00 2001 From: Aditya Oberai Date: Tue, 28 Jul 2026 02:03:06 +0530 Subject: [PATCH 07/18] Update src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc --- .../+page.markdoc | 1 - 1 file changed, 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 81e21d53db..1a2c436afd 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -19,7 +19,6 @@ faqs: - question: Is managed Postgres better than a serverless database? answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. --- -# Managed Postgres vs. serverless databases: Which one should developers choose? **Choose managed Postgres when your workload is steady and you want full control over a proven relational engine. Choose a serverless database when your traffic is spiky or unpredictable and you want to pay only for what you use, scale automatically, and avoid capacity planning.** Both run [PostgreSQL](https://www.postgresql.org/) or a Postgres-compatible engine under the hood, so the real decision is about the operating model, not the query language. From becbf06fe81fbee3a076873cf0ce479bda7dc215 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:38:36 +0530 Subject: [PATCH 08/18] Update +page.markdoc --- .../+page.markdoc | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc index 17430c5a48..9240ec367a 100644 --- a/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc +++ b/src/routes/blog/post/sql-explained-how-developers-query-databases/+page.markdoc @@ -206,11 +206,13 @@ const result = await tablesDB.listRows({ That query does exactly what the SQL `SELECT ... WHERE ... ORDER BY ... LIMIT` earlier in this post does. You get the querying model SQL made standard, plus permissions, realtime updates, and pagination handled for you. And because Appwrite can run on a SQL engine like MariaDB under the hood, you are not locked out of raw SQL when you need it. See how to [integrate SQL, NoSQL, and other databases into your project](/blog/post/integrate-sql-nosql-vector-graph-or-any-database-into-your-appwrite-project) for more. -# Start querying your data with Appwrite Databases +# Start with Appwrite Databases -Understanding SQL gives you a mental model that applies to nearly every database you will ever touch: describe the data you want, and let the engine do the work. Whether you write raw queries or use a Query API, the core ideas of filtering, joining, aggregating, and transactions stay the same. +Appwrite Databases gives you a structured way to store and work with application data without managing the underlying database infrastructure yourself. You can define your data model, store records in tables, control access with permissions, and build applications around the data using Appwrite's database services. -If you want that querying power without managing a database server yourself, [Appwrite Databases](/docs/products/databases) gives you filtering, sorting, and pagination through a clean [Query API](/docs/products/databases/queries), backed by a relational engine and wrapped in permissions and realtime. It is a fast way to put everything in this post into practice. +For developers coming from SQL, the underlying concepts will feel familiar: tables hold structured data, rows represent records, and queries let you filter, sort, and paginate the data you need. Appwrite adds these capabilities as part of its native database experience, alongside permissions and realtime updates. + +To get started, see the [Appwrite Databases documentation](/docs/products/databases) and [databases quick start](/docs/products/databases/quick-start). ## Resources @@ -218,4 +220,4 @@ If you want that querying power without managing a database server yourself, [Ap * [Appwrite Query API: filtering, sorting, and pagination](/blog/post/appwrite-query-api) * [SQL vs NoSQL: Choosing the right database for your project](/blog/post/sql-vs-nosql) * [Integrate SQL, NoSQL, Vector, Graph, or any database into your Appwrite project](/blog/post/integrate-sql-nosql-vector-graph-or-any-database-into-your-appwrite-project) -* Join the [Appwrite Discord community](https://appwrite.io/discord) to ask questions and share what you build. \ No newline at end of file +* Join the [Appwrite Discord community](https://appwrite.io/discord) to ask questions and share what you build. From 3e7974a339e42244cd715c3dd4b0bc878058c4d2 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:43:40 +0530 Subject: [PATCH 09/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 1a2c436afd..96cffb224a 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -1,6 +1,6 @@ --- layout: post -title: "Managed Postgres vs. serverless databases: Which one should developers choose?" +title: "Dedicated Postgres vs. serverless databases: Which one should developers choose?" description: Compare managed Postgres and serverless databases across scaling, pricing, performance, and when to choose each for your app. date: 2026-07-20 cover: /images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.avif From 3df37597fc238461be8d1f385ab965ad27553d5a Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:44:03 +0530 Subject: [PATCH 10/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 96cffb224a..74e2f82bb3 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -1,7 +1,7 @@ --- layout: post title: "Dedicated Postgres vs. serverless databases: Which one should developers choose?" -description: Compare managed Postgres and serverless databases across scaling, pricing, performance, and when to choose each for your app. +description: Compare dedicated Postgres and serverless databases across scaling, pricing, performance, and when to choose each for your app. date: 2026-07-20 cover: /images/blog/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/cover.avif timeToRead: 5 From 54fecd1a71bf5e83b38c7866a8909dcc60505f09 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:45:00 +0530 Subject: [PATCH 11/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 74e2f82bb3..12aa939945 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -20,7 +20,7 @@ faqs: answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. --- -**Choose managed Postgres when your workload is steady and you want full control over a proven relational engine. Choose a serverless database when your traffic is spiky or unpredictable and you want to pay only for what you use, scale automatically, and avoid capacity planning.** Both run [PostgreSQL](https://www.postgresql.org/) or a Postgres-compatible engine under the hood, so the real decision is about the operating model, not the query language. +**Choose dedicated Postgres when your workload is steady and you want dedicated, predictable database capacity. Choose a serverless database when your traffic is spiky or unpredictable and you want compute to scale automatically with demand.** Both can run [PostgreSQL](https://www.postgresql.org/) or a Postgres-compatible engine under the hood, so the real decision is how compute is provisioned and scaled. That distinction matters because picking the wrong model shows up later as a surprise bill, a scaling wall, or a migration you did not budget for. This guide breaks down managed Postgres and serverless databases across scaling, pricing, performance, and operations, then gives you concrete guidance on when to pick each. From cacd29adb0ff8f63d971db12fbc53d2011b804b8 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:45:08 +0530 Subject: [PATCH 12/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 12aa939945..1138124116 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -22,7 +22,7 @@ faqs: **Choose dedicated Postgres when your workload is steady and you want dedicated, predictable database capacity. Choose a serverless database when your traffic is spiky or unpredictable and you want compute to scale automatically with demand.** Both can run [PostgreSQL](https://www.postgresql.org/) or a Postgres-compatible engine under the hood, so the real decision is how compute is provisioned and scaled. -That distinction matters because picking the wrong model shows up later as a surprise bill, a scaling wall, or a migration you did not budget for. This guide breaks down managed Postgres and serverless databases across scaling, pricing, performance, and operations, then gives you concrete guidance on when to pick each. +That distinction matters because picking the wrong model shows up later as a surprise bill, a scaling wall, or a migration you did not budget for. This guide breaks down dedicated Postgres and serverless databases across scaling, pricing, performance, and operations, then gives you concrete guidance on when to pick each. # What is a managed Postgres database? From 3ad20bb17c8adb2fe86765fa453ac2230e77e080 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:46:06 +0530 Subject: [PATCH 13/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 1138124116..02be58625c 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -26,7 +26,7 @@ That distinction matters because picking the wrong model shows up later as a sur # What is a managed Postgres database? -**A managed Postgres database is a PostgreSQL instance that a cloud provider hosts and maintains for you, while you still control its size, configuration, and connection limits.** You pick an instance class, the provider handles backups, patching, replication, and failover, and you pay for that provisioned capacity whether or not it is fully used. +**A dedicated Postgres database gives your application dedicated database capacity that is provisioned for you rather than dynamically scaled per request.** The database can still be hosted and maintained by a cloud provider, which handles tasks such as backups, patching, replication, and failover, while you control the provisioned capacity and configuration. Services like [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/), [Google Cloud SQL](https://cloud.google.com/sql), and Azure Database for PostgreSQL are the common examples. You get a real Postgres server with a fixed amount of CPU, memory, and storage that runs continuously. From 509f968a4dbec613cb975e6456069047286a892c Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:46:13 +0530 Subject: [PATCH 14/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 02be58625c..3c5fc26e9e 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -24,7 +24,7 @@ faqs: That distinction matters because picking the wrong model shows up later as a surprise bill, a scaling wall, or a migration you did not budget for. This guide breaks down dedicated Postgres and serverless databases across scaling, pricing, performance, and operations, then gives you concrete guidance on when to pick each. -# What is a managed Postgres database? +# What is a dedicated Postgres database? **A dedicated Postgres database gives your application dedicated database capacity that is provisioned for you rather than dynamically scaled per request.** The database can still be hosted and maintained by a cloud provider, which handles tasks such as backups, patching, replication, and failover, while you control the provisioned capacity and configuration. From 61db68a878a9a136e2303a47be16332fc3e2eee4 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:49:38 +0530 Subject: [PATCH 15/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 3c5fc26e9e..9ba685f6d8 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -16,7 +16,7 @@ faqs: answer: Some serverless databases can have cold starts when compute scales to zero and needs to resume. This can add latency to the first query after an idle period, so it matters for latency-sensitive applications. - question: Is serverless Postgres the same as managed Postgres? answer: No. Serverless Postgres is still managed, but it uses automatic scaling and usage-based billing. Traditional managed Postgres runs as a provisioned, always-on instance with fixed capacity. - - question: Is managed Postgres better than a serverless database? + - question: Is dedicated Postgres better than a serverless database? answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. --- From 8352f40ff5ab133b3f0cf819e899b48efc36482d Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:49:45 +0530 Subject: [PATCH 16/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 9ba685f6d8..46ff71428d 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -14,7 +14,7 @@ faqs: answer: A serverless database is usually cheaper for low-traffic, spiky, or unpredictable workloads because you pay based on usage. Managed Postgres can be cheaper for steady, high-volume workloads because the provisioned instance is used consistently. - question: Do serverless databases have cold starts? answer: Some serverless databases can have cold starts when compute scales to zero and needs to resume. This can add latency to the first query after an idle period, so it matters for latency-sensitive applications. - - question: Is serverless Postgres the same as managed Postgres? + - question: Is serverless Postgres the same as dedicated Postgres? answer: No. Serverless Postgres is still managed, but it uses automatic scaling and usage-based billing. Traditional managed Postgres runs as a provisioned, always-on instance with fixed capacity. - question: Is dedicated Postgres better than a serverless database? answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. From 1b25ffa43de38df5d0fbe2dadaec96e950b68258 Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 12:49:52 +0530 Subject: [PATCH 17/18] Apply suggestion from @aishwaripahwa12 --- .../+page.markdoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 46ff71428d..52aa725d7b 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -15,7 +15,7 @@ faqs: - question: Do serverless databases have cold starts? answer: Some serverless databases can have cold starts when compute scales to zero and needs to resume. This can add latency to the first query after an idle period, so it matters for latency-sensitive applications. - question: Is serverless Postgres the same as dedicated Postgres? - answer: No. Serverless Postgres is still managed, but it uses automatic scaling and usage-based billing. Traditional managed Postgres runs as a provisioned, always-on instance with fixed capacity. + answer: No. Serverless Postgres is managed by the provider but automatically scales compute based on demand. Dedicated Postgres uses provisioned database capacity that remains available regardless of traffic. - question: Is dedicated Postgres better than a serverless database? answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. --- From 7e0e51e4d92b6044960ae9cfaae5d5d6b67c043b Mon Sep 17 00:00:00 2001 From: Aishwari Pahwa Date: Tue, 28 Jul 2026 13:01:11 +0530 Subject: [PATCH 18/18] Update +page.markdoc --- .../+page.markdoc | 57 ++++++++++--------- 1 file changed, 29 insertions(+), 28 deletions(-) diff --git a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc index 52aa725d7b..16bde54bf6 100644 --- a/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc +++ b/src/routes/blog/post/managed-postgres-vs-serverless-databases-which-one-should-developers-choose/+page.markdoc @@ -10,16 +10,15 @@ category: comparisons featured: false unlisted: true faqs: - - question: Is a serverless database cheaper than managed Postgres? - answer: A serverless database is usually cheaper for low-traffic, spiky, or unpredictable workloads because you pay based on usage. Managed Postgres can be cheaper for steady, high-volume workloads because the provisioned instance is used consistently. +- question: Is a serverless database cheaper than dedicated Postgres? + answer: A serverless database is usually cheaper for low-traffic, spiky, or unpredictable workloads because you pay based on usage. Dedicated Postgres can be cheaper for steady, high-volume workloads because the provisioned capacity is used consistently. - question: Do serverless databases have cold starts? answer: Some serverless databases can have cold starts when compute scales to zero and needs to resume. This can add latency to the first query after an idle period, so it matters for latency-sensitive applications. - question: Is serverless Postgres the same as dedicated Postgres? answer: No. Serverless Postgres is managed by the provider but automatically scales compute based on demand. Dedicated Postgres uses provisioned database capacity that remains available regardless of traffic. - question: Is dedicated Postgres better than a serverless database? - answer: Managed Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need full control over PostgreSQL configuration. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. + answer: Dedicated Postgres is better for steady workloads, predictable traffic, low-latency applications, and teams that need dedicated, predictable database capacity. A serverless database is better for spiky, unpredictable, or low-traffic workloads where automatic scaling and usage-based pricing matter more. --- - **Choose dedicated Postgres when your workload is steady and you want dedicated, predictable database capacity. Choose a serverless database when your traffic is spiky or unpredictable and you want compute to scale automatically with demand.** Both can run [PostgreSQL](https://www.postgresql.org/) or a Postgres-compatible engine under the hood, so the real decision is how compute is provisioned and scaled. That distinction matters because picking the wrong model shows up later as a surprise bill, a scaling wall, or a migration you did not budget for. This guide breaks down dedicated Postgres and serverless databases across scaling, pricing, performance, and operations, then gives you concrete guidance on when to pick each. @@ -28,9 +27,9 @@ That distinction matters because picking the wrong model shows up later as a sur **A dedicated Postgres database gives your application dedicated database capacity that is provisioned for you rather than dynamically scaled per request.** The database can still be hosted and maintained by a cloud provider, which handles tasks such as backups, patching, replication, and failover, while you control the provisioned capacity and configuration. -Services like [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/), [Google Cloud SQL](https://cloud.google.com/sql), and Azure Database for PostgreSQL are the common examples. You get a real Postgres server with a fixed amount of CPU, memory, and storage that runs continuously. +Services like [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/), [Google Cloud SQL](https://cloud.google.com/sql), and Azure Database for PostgreSQL are common examples. You get a Postgres server with a fixed amount of CPU, memory, and storage that runs continuously. -The model is predictable. You know exactly how much compute you have, connection pooling behaves the way you expect, and there are no cold starts. The trade-off is that you provision for peak load, so capacity sits idle during quiet periods and you still pay for it. +The model is predictable. You know exactly how much compute you have, connection pooling behaves the way you expect, and there are no cold starts. The trade-off is that you provision for peak load, so capacity can sit idle during quiet periods while you continue paying for the provisioned capacity. # What is a serverless database? @@ -40,13 +39,13 @@ The model is predictable. You know exactly how much compute you have, connection The appeal is that you stop thinking about capacity. Traffic doubles overnight and the database scales without a manual resize. Traffic drops to nothing and your bill follows. The trade-off is less direct control and, in some implementations, a cold start when the compute layer has scaled to zero and needs to spin back up. -# Managed Postgres vs. serverless databases: The key differences +# Dedicated Postgres vs. serverless databases: The key differences Both options can run identical SQL. The differences live in how they scale, how they charge, how they perform under load, and how much operational work they push back to you. ## Scaling -**Managed Postgres scales vertically and manually.** When you outgrow an instance, you resize it, which usually means a maintenance window or a brief failover to a larger machine. You can add read replicas to spread read traffic, but write scaling and sharding take real engineering effort. +**Dedicated Postgres scales vertically and manually.** When you outgrow your provisioned capacity, you resize it, which can require a maintenance window or a brief failover to a larger machine. You can add read replicas to spread read traffic, but write scaling and sharding take real engineering effort. **Serverless databases scale automatically and elastically.** The compute layer expands to absorb bursts and contracts when demand falls, with no manual resize. This is the single biggest reason teams reach for serverless: unpredictable workloads stop being a capacity-planning problem. @@ -54,44 +53,44 @@ If your load is steady and well understood, manual scaling is rarely a burden. I ## Pricing -**Managed Postgres bills for provisioned capacity.** You pay for the instance around the clock, so a database sized for peak traffic costs the same at 3 a.m. as it does during your busiest hour. For steady, high-utilization workloads this is often the cheaper model because you are not paying a premium for elasticity. +**Dedicated Postgres bills for provisioned capacity.** You pay for the provisioned capacity around the clock, so a database sized for peak traffic costs the same at 3 a.m. as it does during your busiest hour. For steady, high-utilisation workloads this can be the cheaper model because you are not paying a premium for elasticity. -**Serverless databases bill for actual usage,** typically some combination of compute units consumed, storage, and data transfer. For spiky or low-average traffic this can be dramatically cheaper, since idle time costs little or nothing. For sustained high traffic, per-usage pricing can end up more expensive than a right-sized provisioned instance. +**Serverless databases bill for actual usage,** typically some combination of compute units consumed, storage, and data transfer. For spiky or low-average traffic this can be dramatically cheaper, since idle time costs little or nothing. For sustained high traffic, usage-based pricing can end up more expensive than a right-sized dedicated database. -The honest summary: serverless wins on variable and bursty workloads, provisioned wins on steady, predictable ones. Model your real traffic before assuming either is cheaper. +The honest summary: serverless wins on variable and bursty workloads, while dedicated Postgres wins on steady, predictable ones. Model your real traffic before assuming either is cheaper. ## Performance and cold starts -**Managed Postgres delivers consistent, predictable latency** because the server is always running and warm. There is no spin-up penalty, which matters for latency-sensitive applications where every request must be fast. +**Dedicated Postgres delivers consistent, predictable latency** because the database is always running and warm. There is no spin-up penalty, which matters for latency-sensitive applications where every request must be fast. **Serverless databases can introduce cold starts.** When compute has scaled to zero, the first query after an idle period waits for the layer to resume, adding latency to that request. Providers have narrowed this gap considerably, and many keep a warm floor available, but it remains a real consideration for workloads that cannot tolerate an occasional slow first request. -Connection handling also differs. Traditional Postgres has a finite connection limit, and serverless application layers that open many short-lived connections can exhaust it. Serverless databases usually build in pooling to handle this, whereas with managed Postgres you often add a pooler like PgBouncer yourself. +Connection handling also differs. Traditional Postgres has a finite connection limit, and serverless application layers that open many short-lived connections can exhaust it. Serverless databases usually build in pooling to handle this, whereas with dedicated Postgres you may need to add a pooler like PgBouncer yourself. ## Operational overhead -**Managed Postgres removes most, but not all, of the operations work.** The provider handles patching, backups, and failover, but you still own capacity planning, connection pooling strategy, replica configuration, and deciding when to scale up. +**Dedicated Postgres removes most, but not all, of the operations work.** The provider can handle patching, backups, and failover, but you still own capacity planning, connection pooling strategy, replica configuration, and deciding when to scale up. **Serverless databases push more of that to the platform.** Capacity planning largely disappears, and scaling decisions are automatic. You give up some low-level tuning knobs in exchange, which is usually a fair trade for teams that would rather ship features than manage infrastructure. -# Managed Postgres vs. serverless databases at a glance +# Dedicated Postgres vs. serverless databases at a glance -| Aspect | Managed Postgres | Serverless database | +| Aspect | Dedicated Postgres | Serverless database | | ----------- | ----------------------------------------------- | -------------------------------------------- | -| Scaling | Manual, vertical, add replicas | Automatic, elastic, often to zero | -| Pricing | Provisioned capacity, billed continuously | Usage-based, pay for what runs | +| Scaling | Provisioned capacity, scaled manually | Automatic, elastic, often to zero | +| Pricing | Provisioned capacity, billed continuously | Usage-based, pay for what runs | | Latency | Consistent, always warm | Fast when warm, cold starts possible | | Connections | You manage pooling | Pooling usually built in | | Operations | Provider handles maintenance, you plan capacity | Platform handles scaling too | -| Best for | Steady, predictable, high-utilization workloads | Spiky, unpredictable, or low-average traffic | +| Best for | Steady, predictable, high-utilisation workloads | Spiky, unpredictable, or low-average traffic | -# When should you choose managed Postgres? +# When should you choose dedicated Postgres? -Pick managed Postgres when your workload is steady and your access patterns are well understood. If your database runs at consistent utilization most of the day, provisioned pricing is usually cheaper and latency is predictable. +Pick dedicated Postgres when your workload is steady and your access patterns are well understood. If your database runs at consistent utilisation most of the day, provisioned pricing is usually cheaper and latency is predictable. -It is also the stronger choice when you need fine-grained control, such as specific extensions, custom configuration, or a particular connection-pooling setup. And if you are latency-sensitive enough that an occasional cold start would hurt user experience, an always-warm instance removes that risk entirely. +It is also the stronger choice when you need dedicated, predictable capacity and fine-grained control over the database environment, such as specific extensions, custom configuration, or a particular connection-pooling setup. And if you are latency-sensitive enough that an occasional cold start would hurt user experience, an always-warm database removes that risk entirely. -In short, managed Postgres rewards predictability. When you can size for your load and keep utilization high, you get a proven engine with no surprises. +In short, dedicated Postgres rewards predictability. When you can size for your load and keep utilisation high, you get a proven engine with predictable capacity and performance. # When should you choose a serverless database? @@ -99,7 +98,7 @@ Pick a serverless database when your traffic is spiky, seasonal, or genuinely un It also fits teams that want to avoid capacity planning altogether. If you would rather not think about instance sizes and resize windows, letting the platform scale compute automatically frees up real engineering time. -Just weigh the trade-offs honestly. If you know your workload will grow into steady, high-volume traffic, run the numbers, because usage-based pricing can cross over and become more expensive than a right-sized provisioned instance at scale. +Just weigh the trade-offs honestly. If you know your workload will grow into steady, high-volume traffic, run the numbers, because usage-based pricing can cross over and become more expensive than a right-sized dedicated database at scale. # Where a backend platform fits in @@ -107,18 +106,20 @@ Sometimes the real question is not which database engine to run, but how much of [Appwrite Databases](/docs/products/databases) takes an API-first approach: instead of managing connections and raw SQL, you interact with your data through APIs and SDKs, with permissions, queries, and realtime updates built in. It pairs the developer experience of a document model with the rest of a [backend as a service](/blog/post/backend-as-a-service), so auth, storage, and functions live alongside your data. -That is a different trade-off from a bare database, and it is a fair one to name. A pure managed Postgres or serverless Postgres service gives you direct SQL access and maximum control over the engine. A backend platform trades some of that low-level control for speed of development and fewer moving parts to operate. If you are weighing relational against document models more broadly, our breakdown of [SQL vs NoSQL](/blog/post/sql-vs-nosql) and [document vs relational databases](/blog/post/document-vs-relational-databases-vibecoding) go deeper on that decision. +That is a different trade-off from a bare database, and it is a fair one to name. A pure dedicated Postgres or serverless Postgres service gives you direct SQL access and more control over the database engine. A backend platform trades some of that low-level control for speed of development and fewer moving parts to operate. If you are weighing relational against document models more broadly, our breakdown of [SQL vs NoSQL](/blog/post/sql-vs-nosql) and [document vs relational databases](/blog/post/document-vs-relational-databases-vibecoding) go deeper on that decision. # Getting started with Appwrite Databases -The managed-versus-serverless choice comes down to your traffic shape. Steady and predictable favors provisioned managed Postgres. Spiky and unpredictable favors serverless. But if what you actually want is to ship an application without stitching a database together with auth, storage, and functions yourself, a managed backend removes that work entirely. +The dedicated-versus-serverless choice comes down to your traffic shape. Steady and predictable workloads favour dedicated Postgres. Spiky and unpredictable workloads favour serverless. + +But if what you actually want is to ship an application without stitching a database together with auth, storage, and functions yourself, a backend platform removes that work entirely. [Appwrite Databases](/docs/products/databases) gives you a fully managed database with built-in permissions, queries, and realtime updates, alongside authentication, storage, and functions in one platform. You get automated backups and managed scaling on the [free plan](/pricing) as well as paid tiers, with no servers to provision. [Sign up for Appwrite Cloud](https://cloud.appwrite.io/register) and give your next build a backend to grow on in minutes. -## Resources +# Resources * [Appwrite Databases documentation](/docs/products/databases) * [What is serverless? An expert guide for developers](/blog/post/what-is-serverless-an-expert-guide-for-developers) * [SQL vs NoSQL: Choosing the right database for your project](/blog/post/sql-vs-nosql) * [Integrate SQL, NoSQL, Vector, Graph, or any database into your Appwrite project](/blog/post/integrate-sql-nosql-vector-graph-or-any-database-into-your-appwrite-project) -* [Join the Appwrite Discord](https://appwrite.io/discord) \ No newline at end of file +* [Join the Appwrite Discord](https://appwrite.io/discord)