You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: intro/powersync-philosophy.mdx
+6-7Lines changed: 6 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -7,13 +7,13 @@ description: "Our vision is that a local-first or offline-first app architecture
7
7
8
8
The app just works, whether fully online, fully offline, or with spotty connectivity.
9
9
10
-
The app is always fast and responsive — no need to wait for network requests.
10
+
The app is always [fast and responsive](https://www.powersync.com/blog/local-first-is-a-big-deal-especially-for-the-web#to-the-user-everything-feels-instant-no-loading-spinners) — no need to wait for network requests.
11
11
12
12
### What PowerSync means for the developer
13
13
14
-
For the developer, the goal of PowerSync is to solve the hard problems of keeping data in sync, then get out of the way.
14
+
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.
15
15
16
-
You use a standard Postgres, MongoDB or MySQL \[[1](#footnotes)\] database on the server, a standard SQLite database on the client, and your own backend to process writes. PowerSync simply keeps the SQLite database in sync with your backend/server database.
16
+
You use a standard Postgres, MongoDB or MySQL \[[1](#footnotes)\] database on the server, a standard SQLite database on the client, and your [own backend](/installation/app-backend-setup) to process writes. PowerSync simply keeps the SQLite database in sync with your backend/server database.
17
17
18
18
#### State Management
19
19
@@ -28,7 +28,7 @@ Once you have a local SQLite database that is always in sync, [state management]
28
28
29
29
PowerSync allows you to fully customize what data is synced to the client. Syncing the entire database is extremely simple, but it is just as easy to use our [Sync Rules](/usage/sync-rules) to transform and filter data for each client (dynamic partial replication).
30
30
31
-
Writing back to the backend [is in full control of the developer](/installation/app-backend-setup/writing-client-changes) — use your own authentication, validation, and constraints.
31
+
Writing back to the backend database [is in full control of the developer](/installation/app-backend-setup/writing-client-changes) — use your own authentication, validation, and constraints.
32
32
33
33
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.
34
34
@@ -38,17 +38,16 @@ Our goal is also to be stack-agnostic: whether you are switching from MySQL to P
38
38
39
39
#### Simplicity
40
40
41
-
You use plain Postgres, MongoDB or MySQL on the server — no extensions, and no significant change in your schema required \[[2](#footnotes)\]. We [use](/installation/database-setup)the Postgres WAL, MongoDB change streams or MySQL binlog to replicate changes to the [PowerSync Service](/architecture/powersync-service), where data is transformed and partitioned according to [Sync Rules](/usage/sync-rules), and persisted in a way that allows streaming incremental changes to each client.
41
+
You use plain Postgres, MongoDB or MySQL on the server — no extensions, and no significant change in your schema required \[[2](#footnotes)\]. PowerSync [uses](/installation/database-setup) Postgres logical replication, MongoDB change streams or the MySQL binlog to replicate changes to the [PowerSync Service](/architecture/powersync-service), where data is transformed and partitioned according to [Sync Rules](/usage/sync-rules), and persisted in a way that allows efficiently streaming incremental changes to each client.
42
42
43
43
PowerSync has been used in apps with hundreds of tables. There are no complex migrations to run: You define your [Sync Rules](/usage/sync-rules) and [client-side schema](/installation/client-side-setup/define-your-schema), and the data is automatically kept in sync. If you [change Sync Rules](/usage/lifecycle-maintenance/implementing-schema-changes), the entire 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](/usage/lifecycle-maintenance/implementing-schema-changes) to do that without hassle.
44
44
45
-
No need for CRDTs \[3\]. PowerSync is a server-client sync platform — since no peer-to-peer is involved, CRDTs can be overkill. Instead, we use a server reconciliation architecture with a default approach of "last write wins", with capability to [customize the conflict resolution if required](/usage/lifecycle-maintenance/handling-update-conflicts) — the developer is in [full control of the write process](/installation/app-backend-setup/writing-client-changes). Our [strong consistency guarantees](/architecture/consistency) give you peace of mind for the integrity of data on the client.
45
+
No need for CRDTs \[3\]. PowerSync is a server-client sync platform: since no peer-to-peer syncing is involved, CRDTs can be overkill. Instead, we use a server reconciliation architecture with a default approach of "last write wins", with capability to [customize the conflict resolution if required](/usage/lifecycle-maintenance/handling-update-conflicts) — the developer is in [full control of the write process](/installation/app-backend-setup/writing-client-changes). Our [strong consistency guarantees](/architecture/consistency) give you peace of mind for the integrity of data on the client.
0 commit comments