> ## Documentation Index
> Fetch the complete documentation index at: https://powersync-sync-streams-nav.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# PowerSync Philosophy

> PowerSync's vision is that local-first architecture should be easier to implement than cloud-first and deliver a better end-user experience.

## What PowerSync Means for End-Users

The app is always [fast, responsive and reactive](https://www.powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web#to-the-user-everything-feels-instant-no-loading-spinners). There is no need to wait for network requests.

The app just works, whether fully online, fully offline, or with spotty connectivity.

## What PowerSync Means for the Developer

PowerSync lets you avoid the complexities of using APIs to move app state [over the network](https://www.powersync.com/blog/escaping-the-network-tarpit). Its goal is to solve the hard problems of keeping data in sync, without getting in your way.

You use a supported backend source such as Postgres, MongoDB, MySQL, SQL Server, Azure DocumentDB, or Convex on the server, a standard SQLite database on the client, and your [own backend](/configuration/app-backend/setup) to process mutations. PowerSync keeps the SQLite database in sync with your backend source.

### State Management

Once you have a local SQLite database that is always in sync, [state management](https://www.powersync.com/blog/local-first-state-management-with-sqlite) becomes much easier:

* No need for custom caching logic, whether in-memory or persisted.
* No need for maintaining in-memory state across the application.

[All state is in the local database](https://www.powersync.com/blog/local-first-state-management-with-sqlite). Queries are [reactive](/client-sdks/watch-queries): they update whenever the underlying data changes.

### Flexibility

PowerSync allows you to fully customize what data is synced to the client. You can sync the entire database, or use [Sync Streams](/sync/streams/overview) to transform and filter data for each client (<Tooltip tip="Syncing only the relevant subset of data to each client, instead of the entire database.">partial sync</Tooltip>).

Writing back to the backend source database [is in full control of the developer](/handling-writes/writing-client-changes). You can use your own authentication, validation, and constraints.

Our goal is also to be stack-agnostic: whether you are switching from MySQL to Postgres, from Flutter to React Native, or using multiple different stacks - our aim is to maintain maximum engineering optionality for developers.

### Performance

[SQLite is *fast*](https://www.powersync.com/blog/sqlite-optimizations-for-ultra-high-performance). It can perform tens of thousands of updates per second, even faster reads, with support for concurrent reads. Once you get to filtering through thousands of rows in queries, indexes keep the queries fast.

### Simplicity

You use a supported backend source on the server, with no significant change in your schema required for most databases \[[1](#footnotes)]. PowerSync [uses](/configuration/source-db/setup) Postgres logical replication, MongoDB change streams, the MySQL binlog, SQL Server Change Data Capture (CDC), or Convex document deltas to replicate changes to the [PowerSync Service](/architecture/powersync-service), where data is transformed and partitioned according to [Sync Streams](/sync/streams/overview), and persisted in a way that allows efficiently streaming incremental changes to each client.

PowerSync has been used in apps with hundreds of tables. There are no complex migrations to run: You define your [Sync Streams](/sync/streams/overview) and [client-side schema](/intro/setup-guide#define-your-client-side-schema), and the data is automatically kept in sync. If you [change Sync Streams/Rules](/maintenance-ops/implementing-schema-changes), the relevant new set of data is applied atomically on the client. When you do need to make schema changes on the server while still supporting older clients, we [have the processes in place](/maintenance-ops/implementing-schema-changes) to do that without hassle.

No need for CRDTs \[[2](#footnotes)]. PowerSync is a server-client sync platform: since no peer-to-peer syncing is involved, CRDTs can be overkill. Instead, PowerSync uses a server reconciliation architecture, putting the developer in [full control](/handling-writes/writing-client-changes) of how client mutations are applied and managed on the source database. PowerSync imposes no conflict policy: the app backend decides how mutations are applied, while straightforward CRUD implementations commonly produce per-field LWW. Our [causal+ consistency guarantees](/architecture/consistency) give you peace of mind about the integrity of data on the client.

## See Also

* [Local-First Software is a Big Deal, Especially for the Web](https://www.powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web)
* [PowerSync Architecture](/architecture/architecture-overview)

## Footnotes

* \[1] In some cases denormalization is required to effectively partition the data to sync to different users.
* \[2] If you want to use CRDTs for fine-grained collaboration like text editing, we have [examples](/client-sdks/advanced/crdts) of how to do that in conjunction with PowerSync, storing CRDT data in Postgres.