diff --git a/.changeset/late-dryers-brush.md b/.changeset/late-dryers-brush.md
new file mode 100644
index 0000000000..fd0ed63529
--- /dev/null
+++ b/.changeset/late-dryers-brush.md
@@ -0,0 +1,6 @@
+---
+"@electric-sql/next": patch
+"@electric-sql/react": patch
+---
+
+Updated package author, license and homepage.
diff --git a/.gitignore b/.gitignore
index dea33a744d..6c1813d63b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,5 @@
+docs/.vitepress/dist
+docs/.vitepress/cache
json_files
file.jsonl
node_modules
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000000..f433b1a53f
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,177 @@
+
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
+
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+ 1. Definitions.
+
+ "License" shall mean the terms and conditions for use, reproduction,
+ and distribution as defined by Sections 1 through 9 of this document.
+
+ "Licensor" shall mean the copyright owner or entity authorized by
+ the copyright owner that is granting the License.
+
+ "Legal Entity" shall mean the union of the acting entity and all
+ other entities that control, are controlled by, or are under common
+ control with that entity. For the purposes of this definition,
+ "control" means (i) the power, direct or indirect, to cause the
+ direction or management of such entity, whether by contract or
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ outstanding shares, or (iii) beneficial ownership of such entity.
+
+ "You" (or "Your") shall mean an individual or Legal Entity
+ exercising permissions granted by this License.
+
+ "Source" form shall mean the preferred form for making modifications,
+ including but not limited to software source code, documentation
+ source, and configuration files.
+
+ "Object" form shall mean any form resulting from mechanical
+ transformation or translation of a Source form, including but
+ not limited to compiled object code, generated documentation,
+ and conversions to other media types.
+
+ "Work" shall mean the work of authorship, whether in Source or
+ Object form, made available under the License, as indicated by a
+ copyright notice that is included in or attached to the work
+ (an example is provided in the Appendix below).
+
+ "Derivative Works" shall mean any work, whether in Source or Object
+ form, that is based on (or derived from) the Work and for which the
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
+ of this License, Derivative Works shall not include works that remain
+ separable from, or merely link (or bind by name) to the interfaces of,
+ the Work and Derivative Works thereof.
+
+ "Contribution" shall mean any work of authorship, including
+ the original version of the Work and any modifications or additions
+ to that Work or Derivative Works thereof, that is intentionally
+ submitted to Licensor for inclusion in the Work by the copyright owner
+ or by an individual or Legal Entity authorized to submit on behalf of
+ the copyright owner. For the purposes of this definition, "submitted"
+ means any form of electronic, verbal, or written communication sent
+ to the Licensor or its representatives, including but not limited to
+ communication on electronic mailing lists, source code control systems,
+ and issue tracking systems that are managed by, or on behalf of, the
+ Licensor for the purpose of discussing and improving the Work, but
+ excluding communication that is conspicuously marked or otherwise
+ designated in writing by the copyright owner as "Not a Contribution."
+
+ "Contributor" shall mean Licensor and any individual or Legal Entity
+ on behalf of whom a Contribution has been received by Licensor and
+ subsequently incorporated within the Work.
+
+ 2. Grant of Copyright License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ copyright license to reproduce, prepare Derivative Works of,
+ publicly display, publicly perform, sublicense, and distribute the
+ Work and such Derivative Works in Source or Object form.
+
+ 3. Grant of Patent License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ (except as stated in this section) patent license to make, have made,
+ use, offer to sell, sell, import, and otherwise transfer the Work,
+ where such license applies only to those patent claims licensable
+ by such Contributor that are necessarily infringed by their
+ Contribution(s) alone or by combination of their Contribution(s)
+ with the Work to which such Contribution(s) was submitted. If You
+ institute patent litigation against any entity (including a
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
+ or a Contribution incorporated within the Work constitutes direct
+ or contributory patent infringement, then any patent licenses
+ granted to You under this License for that Work shall terminate
+ as of the date such litigation is filed.
+
+ 4. Redistribution. You may reproduce and distribute copies of the
+ Work or Derivative Works thereof in any medium, with or without
+ modifications, and in Source or Object form, provided that You
+ meet the following conditions:
+
+ (a) You must give any other recipients of the Work or
+ Derivative Works a copy of this License; and
+
+ (b) You must cause any modified files to carry prominent notices
+ stating that You changed the files; and
+
+ (c) You must retain, in the Source form of any Derivative Works
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
+
+ (d) If the Work includes a "NOTICE" text file as part of its
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
+
+ You may add Your own copyright statement to Your modifications and
+ may provide additional or different license terms and conditions
+ for use, reproduction, or distribution of Your modifications, or
+ for any such Derivative Works as a whole, provided Your use,
+ reproduction, and distribution of the Work otherwise complies with
+ the conditions stated in this License.
+
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
+ any Contribution intentionally submitted for inclusion in the Work
+ by You to the Licensor shall be under the terms and conditions of
+ this License, without any additional terms or conditions.
+ Notwithstanding the above, nothing herein shall supersede or modify
+ the terms of any separate license agreement you may have executed
+ with Licensor regarding such Contributions.
+
+ 6. Trademarks. This License does not grant permission to use the trade
+ names, trademarks, service marks, or product names of the Licensor,
+ except as required for reasonable and customary use in describing the
+ origin of the Work and reproducing the content of the NOTICE file.
+
+ 7. Disclaimer of Warranty. Unless required by applicable law or
+ agreed to in writing, Licensor provides the Work (and each
+ Contributor provides its Contributions) on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied, including, without limitation, any warranties or conditions
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+ PARTICULAR PURPOSE. You are solely responsible for determining the
+ appropriateness of using or redistributing the Work and assume any
+ risks associated with Your exercise of permissions under this License.
+
+ 8. Limitation of Liability. In no event and under no legal theory,
+ whether in tort (including negligence), contract, or otherwise,
+ unless required by applicable law (such as deliberate and grossly
+ negligent acts) or agreed to in writing, shall any Contributor be
+ liable to You for damages, including any direct, indirect, special,
+ incidental, or consequential damages of any character arising as a
+ result of this License or out of the use or inability to use the
+ Work (including but not limited to damages for loss of goodwill,
+ work stoppage, computer failure or malfunction, or any and all
+ other commercial damages or losses), even if such Contributor
+ has been advised of the possibility of such damages.
+
+ 9. Accepting Warranty or Additional Liability. While redistributing
+ the Work or Derivative Works thereof, You may choose to offer,
+ and charge a fee for, acceptance of support, warranty, indemnity,
+ or other liability obligations and/or rights consistent with this
+ License. However, in accepting such obligations, You may act only
+ on Your own behalf and on Your sole responsibility, not on behalf
+ of any other Contributor, and only if You agree to indemnify,
+ defend, and hold each Contributor harmless for any liability
+ incurred by, or claims asserted against, such Contributor by reason
+ of your accepting any such warranty or additional liability.
+
+ END OF TERMS AND CONDITIONS
diff --git a/docs/.vitepress/config.mts b/docs/.vitepress/config.mts
new file mode 100644
index 0000000000..ad408f6fdd
--- /dev/null
+++ b/docs/.vitepress/config.mts
@@ -0,0 +1,83 @@
+import { defineConfig } from 'vitepress'
+
+// https://vitepress.dev/reference/site-config
+export default defineConfig({
+ lang: 'en',
+ title: "Electric Next",
+ description: "Your data, in sync, wherever you need it.",
+ appearance: 'force-dark',
+ base: '/',
+ cleanUrls: true,
+ head: [
+ ['link', {
+ rel: 'icon',
+ type: 'image/svg+xml',
+ href: '/img/brand/favicon.svg'
+ }]
+ ],
+ // https://vitepress.dev/reference/default-theme-config
+ themeConfig: {
+ logo: '/img/brand/logo.svg',
+ nav: [
+ { text: 'About', link: '/about' },
+ { text: 'Product', link: '/product/electric', activeMatch: '/product/' },
+ { text: 'Guides', link: '/guides/quickstart', activeMatch: '/guides/'},
+ { text: 'API', link: '/api/http', activeMatch: '/api/'},
+ { text: 'Examples', link: '/examples/basic', activeMatch: '/examples/'},
+ ],
+ sidebar: [
+ {
+ text: 'About',
+ items: [
+ { text: 'electric-next', link: '/about' }
+ ]
+ },
+ {
+ text: 'Product',
+ items: [
+ { text: 'Electric', link: '/product/electric' },
+ { text: 'DDN', link: '/product/ddn' },
+ { text: 'PGlite', link: '/product/pglite' },
+ ]
+ },
+ {
+ text: 'Guides',
+ items: [
+ { text: 'Quickstart', link: '/guides/quickstart' },
+ { text: 'Usage', link: '/guides/usage' },
+ { text: 'Deployment', link: '/guides/deployment' },
+ { text: 'Write your own client', link: '/guides/write-your-own-client' }
+ ]
+ },
+ {
+ text: 'API',
+ items: [
+ { text: 'HTTP', link: '/api/http' },
+ {
+ text: 'Clients',
+ items: [
+ { text: 'JavaScript', link: '/api/clients/js' },
+ { text: 'Elixir', link: '/api/clients/elixir' },
+ ],
+ collapsed: false
+ },
+ {
+ text: 'Connectors',
+ items: [
+ { text: 'MobX', link: '/api/connectors/mobx' },
+ { text: 'React', link: '/api/connectors/react' },
+ { text: 'Redis', link: '/api/connectors/redis' },
+ { text: 'TanStack', link: '/api/connectors/tanstack' },
+ ],
+ collapsed: false
+ }
+ ]
+ }
+ ],
+ siteTitle: false,
+ socialLinks: [
+ { icon: 'discord', link: 'https://discord.electric-sql.com' },
+ { icon: 'github', link: 'https://github.com/electric-sql/electric-sql' }
+ ]
+ }
+})
diff --git a/docs/.vitepress/theme/custom.css b/docs/.vitepress/theme/custom.css
new file mode 100644
index 0000000000..b341d5a640
--- /dev/null
+++ b/docs/.vitepress/theme/custom.css
@@ -0,0 +1,114 @@
+@import url('https://fonts.googleapis.com/css2?family=Inter:wght@300..700&display=swap');
+
+:root, .dark {
+ --vp-c-indigo-1: #D0BCFF;
+ --vp-c-indigo-2: #998FE7;
+ --vp-c-indigo-3: #7E78DB;
+
+ --vp-nav-logo-height: 30px;
+
+ --vp-c-text-1: rgba(255, 255, 245, 0.92);
+ --vp-c-text-2: rgba(235, 235, 245, 0.75);
+ --vp-c-text-3: rgba(235, 235, 245, 0.55);
+
+ --electric-color: #00D2A0;
+ --ddn-color: #D0BCFF;
+ --pglite-color: #F6F95C;
+}
+
+.img-row {
+ display: grid;
+ grid-template-columns: repeat(1, 1fr);
+ flex-direction: row;
+ margin: 20px 0;
+ gap: 10px;
+}
+.img-row-2 {
+ grid-template-columns: repeat(2, 1fr);
+}
+@media (max-width: 767px) {
+ .img-row-2 {
+ grid-template-columns: repeat(1, 1fr);
+ }
+}
+.img-border {
+ border: 1px #ccc solid;
+ border-radius: 10px;
+ padding: 10px;
+ background: rgb(20, 21, 23);
+}
+figure {
+ margin: 40px 0;
+}
+figcaption {
+ text-align: right;
+ font-size: 90%;
+ max-width: 460px;
+ margin-left: auto;
+}
+
+iframe {
+ color-scheme: auto;
+}
+.twitter-tweet {
+ margin: 35px auto -95px !important;
+}
+.twitter-tweet iframe {
+ transform: scale(0.8);
+ transform-origin: top left;
+}
+
+.VPHomeHero .VPImage.image-src {
+ max-width: min(calc(250px + 25vw), 560px);
+ margin-left: -40px;
+ margin-top: 10px;
+}
+@media (max-width: 959px) {
+ .VPHomeHero .image .image-container {
+ height: calc(190px + 15vw) !important;
+ margin-top: -20px;
+ }
+ .VPHomeHero .VPImage.image-src {
+ margin-left: 0px;
+ }
+}
+
+.VPFeatures {
+ padding-top: 15px !important;
+ padding-bottom: 45px;
+}
+.VPFeature .VPImage {
+ width: 50px;
+}
+.VPFeature h2.title {
+ font-size: 20px;
+}
+.VPFeature.link[href="/product/electric"]:hover {
+ border-color: var(--electric-color);
+}
+.VPFeature.link[href="/product/pglite"]:hover {
+ border-color: var(--pglite-color);
+}
+
+.VPFeature .details {
+ font-weight: 600 !important;
+}
+
+.product-icon {
+ width: 84px;
+ margin-bottom: 20px;
+}
+
+.about-zap {
+ max-width: min(calc(150px + 25vw), 420px);
+ margin: -20px 0 30px;
+}
+@media (max-width: 767px) {
+ .about-zap-container {
+ display: none;
+ }
+}
+
+.vp-doc blockquote {
+ margin: 25px 10px 30px;
+}
\ No newline at end of file
diff --git a/docs/.vitepress/theme/index.js b/docs/.vitepress/theme/index.js
new file mode 100644
index 0000000000..8dadef36b4
--- /dev/null
+++ b/docs/.vitepress/theme/index.js
@@ -0,0 +1,5 @@
+// .vitepress/theme/index.js
+import DefaultTheme from 'vitepress/theme-without-fonts'
+import './custom.css'
+
+export default DefaultTheme
\ No newline at end of file
diff --git a/docs/about.md b/docs/about.md
new file mode 100644
index 0000000000..5d2100fd17
--- /dev/null
+++ b/docs/about.md
@@ -0,0 +1,320 @@
+---
+outline: [2, 3]
+title: About
+description: >-
+ Electric Next is an experimental new approach to
+ building the ElectricSQL sync engine.
+---
+
+
+
+
+
+
+
+# A new approach to building Electric
+
+| Authored by | Published on |
+| ----------- | ------------ |
+| [James Arthur](https://electric-sql.com/about/team#kyle) | 17th July 2024 |
+
+ [`electric-next`](https://github.com/electric-sql/electric-next) is an experimental new approach to building ElectricSQL.
+
+One that's informed by the lessons learned building the [previous system](https://electric-sql.com) and inspired by new insight from [Kyle Mathews](https://electric-sql.com/about/team#kyle).
+
+What started as tinkering in private now looks certain to be the way forward for Electric. So, what it is, what's changed and what does it mean for you?
+
+
+## What is `electric-next`?
+
+[`electric-next`](https://github.com/electric-sql/electric-next) is a clean rebuild of the Electric sync engine.
+
+We created a new repo at [electric-sql/electric-next](https://github.com/electric-sql/electric-next) and started by porting the absolute minimum code necessary from the previous repo.
+
+It provides an [HTTP API](/api/http) for syncing [Shapes](https://electric-sql.com/docs/usage/data-access/shapes) of data from Postgres. This can be used directly or via [client libraries](/api/clients/js) and [connectors](/api/connectors/mobx).
+
+It's also simple to [write your own client](/guides/write-your-own-client) in any language.
+
+## Why build a new system?
+
+Electric has its [heritage](https://electric-sql.com/about/team#advisors) in [distributed database research](https://electric-sql.com/docs/reference/literature). When we started, our plan was to use this research to build a next-generation distributed database. Cockroach for the AP side of the CAP theorem. However, the adoption dynamics for creating a new database from scratch are tough. So we pivoted to building a replication layer for existing databases.
+
+This allowed us to do active-active replication between multiple Postgres instances, in the cloud or at the edge. However, rather than stopping at the edge, we kept seeing that it was more optimal to take the database-grade replication guarantees all the way into the client.
+
+So we built a system to sync data into embedded databases in the client. Where our core technology could solve the concurrency challenges with local-first software architecture. Thus, ElectricSQL was born, as an [open source platform for building local-first software](https://electric-sql.com).
+
+### Optimality and complexity
+
+To go from core database replication technology to a viable solution for building local-first software, we had to build a lot of stuff. Tooling for [migrations](https://electric-sql.com/docs/usage/data-modelling/migrations), [permissions](https://electric-sql.com/docs/usage/data-modelling/permissions), [client generation](https://electric-sql.com/docs/api/cli#generate), [type-safe data access](https://electric-sql.com/docs/usage/data-access/client), [live queries](https://electric-sql.com/docs/integrations/frontend/react#uselivequery), [reactivity](https://electric-sql.com/docs/reference/architecture#reactivity), [drivers](https://electric-sql.com/docs/integrations/drivers), etc.
+
+
+
+
+ Schema evolution diagramme from the previous
+
+ architecture page.
+
+
+
+Coming from a research background, we wanted the system to be optimal. As a result, we often picked the more complex solution from the design space and, as a vertically integrated system, that solution became the only one available to use with Electric.
+
+For example, we designed the [DDLX rule system](https://electric-sql/docs/api/ddlx) in a certain way, because we wanted authorization that supported finality of local writes. However, rules (and our rules) are only one way to do authorization in a local-first system. Many applications would be happy with a simpler solution, such as Postgres RLS or a server authoritative middleware.
+
+These decisions not only made Electric more complex to use but also more complex to develop. Despite our best efforts, this has slowed us down and tested the patience of even the most forgiving of our early adopters.
+
+
+
+Many of those early adopters have also reported performance and reliability issues.
+
+The complexity of the stack has provided a wide surface for bugs. So where we've wanted to be focusing on core features, performance and stability, we've ended up fixing issues with things like [docker networking](https://github.com/electric-sql/electric/issues/582), [migration tooling](https://github.com/electric-sql/electric/issues/668) and [client-side build tools](https://github.com/electric-sql/electric/issues/798).
+
+The danger, articulated by [Teej](https://x.com/teej_m) in the tweet below, is building a system that demos well, with magic sync APIs but that never actually scales out reliably. Because the very features and choices that make the demo magic, prevent the system from being simple enough to be bulletproof in production.
+
+
+
+### Refocusing our product strategy
+
+One of the many insights that Kyle has brought is that successful systems evolve from simple systems that work. This is [Gall's law](https://archive.org/details/systemanticshows00gall):
+
+> “A complex system that works is invariably found to have evolved from a simple system that worked.”
+
+This has been echoed in conversations we've had with [Paul Copplestone](https://linkedin.com/in/paulcopplestone) at [Supabase](https://supabase.com). His approach to successfully building our type of software is to make the system incremental and composable, as reflected in the [Supabase Architecture](https://supabase.com/docs/guides/getting-started/architecture) guide:
+
+> Supabase is composable. Even though every product works in isolation, each product on the platform needs to 10x the other products.
+
+To make a system that's incremental and composable, we need to decouple the Electric stack. So it's not a one-size-fits-all vertical stack but, instead, more of a loosely coupled set of primitives around a smaller core. Where we do the essential bits and then allow our users to choose how to integrate and compose these with other layers of the stack.
+
+This aligns with the principle of [Worse is Better](https://en.wikipedia.org/wiki/Worse_is_better), defined by Richard P. Gabriel:
+
+> Software quality does not necessarily increase with functionality: there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability.
+
+Gabriel contrasts "Worse is Better" with a make the "Right Thing" approach that aims to create the optimal solution. Which sounds painfully like our ambitions to make an optimal local-first platform. Whereas moving functionality out of scope, will actually allow us to make the core better and deliver on the opportunity.
+
+#### The motivation for `electric-next`
+
+So, hopefully now our motivation is clear. We need to find a way to simplify Electric and make it more loosely coupled. To pare it back to it's core and iterate on solid foundations.
+
+
+## What's changed?
+
+`electric-next` is a sync engine, not a local-first software platform.
+
+It can be used for a wide range of use cases, syncing data into apps, workers, services, agents and environments. These include but are not limited to local-first software development.
+
+### Sync engine
+
+When we look at our stack, the part that we see as most core is the sync engine.
+
+This is the component of Electric that syncs data between Postgres and local clients. Consuming Postgres logical replication, managing partial replication using Shapes and syncing data to and from clients over a replication protocol. It’s where there’s the most complexity. Where we can add the most value and is hardest to develop yourself.
+
+#### Core responsibilities
+
+We now see Electric as a sync engine that does partial replication on top of Postgres. We've pushed other, non-core, aspects of the system out of scope, as we pare down to our essential core and then iterate on this to re-build the capabilities of the previous system.
+
+
+
+
+ Diagramme illustrating core system responsibilities vs optional layers and integrations.
+
+
+
+The diagramme above and table below summarise what we see as core and what we've pushed out of scope.
+
+| Aspect | Is it core? | Who should/can provide? |
+| --- | --- | --- |
+| Syncing data | yes | Electric |
+| Partial replication ([Shapes](https://electric-sql.com/docs/usage/data-access/shapes)) | yes | Electric |
+| Schema management / propagation / matching | partial | Application specific. In some cases it may be useful or necessary to replicate and validate schema information. In others, it can be the responsibility of the client to connect with the correct schema. |
+| Type safety in the client | partial | Important in many cases for DX and can be assisted by the sync service (e.g.: by providing an endpoint to query types for a shape). But use of types is optional and in many cases types can be provided by ORMs and other client-libraries. |
+| Permissions / authorization | no | There are many valid patterns here. Auth middleware, proxies, rule systems. Authorize at connect, per shape, per row/operation. A sync engine may provide some hooks and options but should not prescribe a solution. |
+| Client-side data access library | no | There are many ways of mapping a replication stream to objects, graphs or databases in the client. For example using existing ORMs like Drizzle and Prisma, or reactivity frameworks like LiveStore and TinyBase. |
+| Client-side reactivity | no | Client specific. Can be provided by reactivity frameworks. |
+| Connection management | no | Client specific. |
+| Database adapters | no | Client specific. Can be provided by ORMs and reactivity frameworks. |
+| Framework integrations | no | Client specific. Can be provided by reactivity frameworks. |
+| Client-side debug tooling | no | Client specific. |
+
+### HTTP Protocol
+
+One of the key aspects that has changed in the core sync engine is a switch from the [Satellite web socket replication prototol](https://electric-sql.com/docs/api/satellite) to an HTTP replication protocol.
+
+Switching to an HTTP protocol may at first seem like a regression or a strange fit. Web sockets are build on top of HTTP specifically to serve the kind of realtime data stream that Electric provides. However, they are also more stateful and harder to cache.
+
+By switching to the [new HTTP API](/api/http), the new system:
+
+- minimises state, making the sync engine more reliable and easier to scale out
+- integrates with standard HTTP tooling, including proxies and CDNs
+
+This allows us to optimise initial data sync by making sync requests cacheable. And it facilitates moving concerns like authentication and authorization out of scope, as these can be handled by HTTP proxies.
+
+### Write patterns
+
+Electric has always been envisaged as an active-active replication system that supports bi-directional sync between clients and the server. This means it syncs data out to clients (the "read path") and syncs data back from clients (the "write path").
+
+The previous Electric supported a single primary write-path pattern — [writing through the local database](https://electric-sql.com/docs/usage/data-access/writes):
+
+
+
+
+ Data flow diagramme from the previous
+
+ architecture page.
+
+
+
+This is very powerful (and [abstracts state transfer](https://electric-sql.com/blog/2022/12/16/evolution-state-transfer) out of the application domain). However, it is only one of many valid write patterns.
+
+Many applications don't write data at all; for example, syncing data into an application for visualisation or analysis. Some fire-and-forget writes to an ingest API. Other applications write data via API calls, or mutation queues. Some of these are online writes. Some use local optimistic state.
+
+For example, when applying a mutation with [Relay](https://relay.dev) you can [define an `optimisticResponse`](https://relay.dev/docs/guided-tour/updating-data/imperatively-modifying-store-data/#optimistic-updaters-vs-updaters) to update the client store with temporary optimistic state whilst the write is sent to the server. Or to give another example, when [making secure transactions](https://electric-sql.com/blog/2023/12/15/secure-transactions-with-local-first) a local-first app will explicitly want to send writes to the server, in order to validate and apply them in a secure and strongly consistent environment.
+
+So, following the strategy of paring down to the core and then progressively layering on more complex functionality, `electric-next` has taken the following approach:
+
+1. start with read-path only
+2. then add support for optimistic write patterns with tentativity
+3. then add support for through-the-DB writes
+
+This explicitly reduces the capability of the system in the short term, in order to build a better, more resilient system in the long term. The beauty is also that you are — that anyone is — free to build systems using any write-path strategy on top of this and it will just work, from day one. We no longer prescribe a write-path strategy. Instead, if you can get the data into Postgres, Electric will sync it out.
+
+We recognise that the sync engine can facilitate different strategies by providing appropriate metadata in the replication stream. For example, helping you see when you writes have synced.
+
+In addition, we still believe in the optimality of writing through the local database and intend to both provide first-class APIs for handling database write operations and contribute to the ecosystem by developing client-side libraries to support more complex write patterns where they're needed.
+
+However, we will only focus on these more complex strategies ourseves once the simpler ones are bulletproof. And we hope that others, like [LiveStore](https://www.schickling.dev/projects/livestore) and [Drizzle](https://orm.drizzle.team/), for example, will build better client-side libraries that we can.
+
+#### A note on finality of local writes
+
+One of the key differentiators of the previous ElectricSQL system was the ability to write to the local database without conflicts or rollbacks. The principle is [finality of local-writes](https://electric-sql.com/docs/reference/architecture#local-writes), which means that writes are final, not tentative. I.e.: once a write is accepted locally, it won't be rejected as invalid later on.
+
+In contrast, `electric-next` embraces tentativity. With the new system, you can choose your write pattern(s) and the guarantees you want them to provide.
+
+We still believe that a local-first stack that provides finality of local writes can provide a better DX and UX than one that doesn't. Because of the absence of rollbacks. So we are committed in the longer term to building support for finality of local writes. However, it is no longer a key tenet of the system design.
+
+### Use cases
+
+The core use case for Electric is to sync subsets of data out of Postgres into local environments, wherever you need the data.
+
+
+
+
+
+ 
+
+ 
+
+ 
+
+ 
+
+# Data Delivery Network
+
+Load data faster than you can query Postgres,
+scale out to millions of users.
+
+## Use cases
+
+This allows you to scale out real-time data to millions of concurrent users from a single commodity Postgres. With blazing fast load times, minimal latency and low resource use.
+
+
+
+## How does it work?
+
+`electric-next` has been designed from the ground up to deliver fast initial data loads and low latency ongoing sync. It exposes this through an [HTTP API](/api/http) that provides standard caching headers to integrates out-of-the-box with CDNs like Cloudflare and Fastly.
+
+## How do I use it?
+
+
+
+Run Electric and put it behind a CDN.
+
+We will add more detailed guide and example content. For now, see the [sync-service/dev/nginx.conf](https://github.com/electric-sql/electric-next/blob/main/packages/sync-service/dev/nginx.conf) and [typescript-client/test/cache.test.ts](https://github.com/electric-sql/electric-next/blob/main/packages/typescript-client/test/cache.test.ts) for example usage.
diff --git a/docs/product/electric.md b/docs/product/electric.md
new file mode 100644
index 0000000000..ce78bdcaa6
--- /dev/null
+++ b/docs/product/electric.md
@@ -0,0 +1,38 @@
+---
+outline: deep
+---
+
+
+
+# Electric Sync Engine
+
+Sync partial replicas of your data into local
+apps and services.
+
+## Use cases
+
+The Electric Sync Engine syncs subsets of data out of Postgres into local apps, services and environments — wherever you need the data.
+
+
+
+You can sync data into:
+
+- web and mobile apps, [replacing data fetching with data sync](/examples/linearlite)
+- development environments, for example syncing data into [an embedded PGlite](/product/pglite)
+- edge workers and services, for example maintaining a low-latency [edge data cache](/api/connectors/redis)
+- local AI systems running RAG, for example [using pgvector](https://electric-sql.com/blog/2024/02/05/local-first-ai-with-tauri-postgres-pgvector-llama)
+- databases like [PGlite](./pglite)
+
+## How does it work?
+
+The Electric sync engine is an [Elixir](https://elixir-lang.org) application, developed at [electric-sql/electric-next/tree/main/packages/sync-service](https://github.com/electric-sql/electric-next/tree/main/packages/sync-service).
+
+It connects to your Postgres using a `DATABASE_URL`, consumes the logical replication stream and provides [an HTTP API](/api/http) for replicating [Shapes](https://electric-sql.com/docs/usage/data-access/shapes).
+
+## How do I use it?
+
+See the [Quickstart](/guides/quickstart) and [Examples](/examples/basic).
diff --git a/docs/product/pglite.md b/docs/product/pglite.md
new file mode 100644
index 0000000000..8f0261743e
--- /dev/null
+++ b/docs/product/pglite.md
@@ -0,0 +1,38 @@
+---
+outline: deep
+---
+
+
+
+# PGlite
+
+Embed a lightweight client Postgres with
+real-time, reactive bindings.
+
+## Use cases
+
+PGlite is a lightweight WASM Postgres build, packaged into a TypeScript library for the browser, Node.js, Bun and Deno.
+
+
+
+PGlite allows you to run Postgres in the browser, Node.js and Bun, with no need to install any other dependencies. It is only 2.6mb gzipped.
+
+```js
+import { PGlite } from "@electric-sql/pglite";
+
+const db = new PGlite();
+await db.query("select 'Hello world' as message;");
+// -> { rows: [ { message: "Hello world" } ] }
+```
+
+It can be used as an ephemeral in-memory database, or with persistence either to the file system (Node/Bun) or indexedDB (Browser).
+
+## How does it work?
+
+Unlike previous "Postgres in the browser" projects, PGlite does not use a Linux virtual machine - it is simply Postgres in WASM, compiled using [Emscripten](https://en.wikipedia.org/wiki/Emscripten). It provides a mechanism for dynamic extension loading, debug tooling and an in-browser repl.
+
+## How do I use it?
+
+See the [electric-sql/pglite](https://github.com/electric-sql/pglite) repo for more details.
diff --git a/docs/public/favicon.ico b/docs/public/favicon.ico
new file mode 100644
index 0000000000..55765b6d89
Binary files /dev/null and b/docs/public/favicon.ico differ
diff --git a/docs/public/img/about/data-flow.jpg b/docs/public/img/about/data-flow.jpg
new file mode 100644
index 0000000000..e62d46e6b3
Binary files /dev/null and b/docs/public/img/about/data-flow.jpg differ
diff --git a/docs/public/img/about/in-and-out-of-scope.jpg b/docs/public/img/about/in-and-out-of-scope.jpg
new file mode 100644
index 0000000000..212a68d0c1
Binary files /dev/null and b/docs/public/img/about/in-and-out-of-scope.jpg differ
diff --git a/docs/public/img/about/in-and-out-of-scope.png b/docs/public/img/about/in-and-out-of-scope.png
new file mode 100644
index 0000000000..5d0dc06f8c
Binary files /dev/null and b/docs/public/img/about/in-and-out-of-scope.png differ
diff --git a/docs/public/img/about/schema-evolution.jpg b/docs/public/img/about/schema-evolution.jpg
new file mode 100644
index 0000000000..8e81f646ec
Binary files /dev/null and b/docs/public/img/about/schema-evolution.jpg differ
diff --git a/docs/public/img/about/use-cases.jpg b/docs/public/img/about/use-cases.jpg
new file mode 100644
index 0000000000..17a2f1bee1
Binary files /dev/null and b/docs/public/img/about/use-cases.jpg differ
diff --git a/docs/public/img/about/use-cases.png b/docs/public/img/about/use-cases.png
new file mode 100644
index 0000000000..980c3250da
Binary files /dev/null and b/docs/public/img/about/use-cases.png differ
diff --git a/docs/public/img/about/use-cases.sm.png b/docs/public/img/about/use-cases.sm.png
new file mode 100644
index 0000000000..724ffbc2cb
Binary files /dev/null and b/docs/public/img/about/use-cases.sm.png differ
diff --git a/docs/public/img/brand/favicon.svg b/docs/public/img/brand/favicon.svg
new file mode 100644
index 0000000000..710e1d9bec
--- /dev/null
+++ b/docs/public/img/brand/favicon.svg
@@ -0,0 +1,4 @@
+
diff --git a/docs/public/img/brand/logo.svg b/docs/public/img/brand/logo.svg
new file mode 100644
index 0000000000..70dbd56afa
--- /dev/null
+++ b/docs/public/img/brand/logo.svg
@@ -0,0 +1,13 @@
+
diff --git a/docs/public/img/home/zap-with-halo.svg b/docs/public/img/home/zap-with-halo.svg
new file mode 100644
index 0000000000..4873f8c3d6
--- /dev/null
+++ b/docs/public/img/home/zap-with-halo.svg
@@ -0,0 +1,44 @@
+
diff --git a/docs/public/img/icons/ddn.svg b/docs/public/img/icons/ddn.svg
new file mode 100644
index 0000000000..9539ceef64
--- /dev/null
+++ b/docs/public/img/icons/ddn.svg
@@ -0,0 +1,9 @@
+
diff --git a/docs/public/img/icons/electric.svg b/docs/public/img/icons/electric.svg
new file mode 100644
index 0000000000..d605e8e0df
--- /dev/null
+++ b/docs/public/img/icons/electric.svg
@@ -0,0 +1,4 @@
+
diff --git a/docs/public/img/icons/pglite.svg b/docs/public/img/icons/pglite.svg
new file mode 100644
index 0000000000..c74e70c13b
--- /dev/null
+++ b/docs/public/img/icons/pglite.svg
@@ -0,0 +1,3 @@
+
diff --git a/docs/public/robots.txt b/docs/public/robots.txt
new file mode 100644
index 0000000000..c2a49f4fb8
--- /dev/null
+++ b/docs/public/robots.txt
@@ -0,0 +1,2 @@
+User-agent: *
+Allow: /
diff --git a/packages/react-hooks/package.json b/packages/react-hooks/package.json
index 6987bb0428..28f0583cc4 100644
--- a/packages/react-hooks/package.json
+++ b/packages/react-hooks/package.json
@@ -19,12 +19,12 @@
"type": "git",
"url": "git+https://github.com/electric-sql/electric-next.git"
},
- "author": "",
- "license": "ISC",
+ "author": "ElectricSQL team and contributors.",
+ "license": "Apache-2",
"bugs": {
"url": "https://github.com/electric-sql/electric-next/issues"
},
- "homepage": "https://github.com/electric-sql/electric-next#readme",
+ "homepage": "https://next.electric-sql.com",
"dependencies": {
"@electric-sql/next": "workspace:*"
},
diff --git a/packages/typescript-client/package-lock.json b/packages/typescript-client/package-lock.json
index 67d612717e..705062c69c 100644
--- a/packages/typescript-client/package-lock.json
+++ b/packages/typescript-client/package-lock.json
@@ -7441,4 +7441,4 @@
}
}
}
-}
+}
\ No newline at end of file
diff --git a/packages/typescript-client/package.json b/packages/typescript-client/package.json
index 4b229b83e2..ae22ce0817 100644
--- a/packages/typescript-client/package.json
+++ b/packages/typescript-client/package.json
@@ -1,7 +1,7 @@
{
"name": "@electric-sql/next",
"version": "0.0.2",
- "description": "The Next Electric",
+ "description": "Postgres everywhere - your data, in sync, wherever you need it.",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"files": [
@@ -20,12 +20,12 @@
"type": "git",
"url": "git+https://github.com/electric-sql/electric-next.git"
},
- "author": "",
- "license": "ISC",
+ "author": "ElectricSQL team and contributors.",
+ "license": "Apache-2",
"bugs": {
"url": "https://github.com/electric-sql/electric-next/issues"
},
- "homepage": "https://github.com/electric-sql/electric-next#readme",
+ "homepage": "https://next.electric-sql.com",
"dependencies": {},
"devDependencies": {
"@redocly/cli": "^1.18.0",