James Arthur

James Arthur is a co-founder of Electric and an engineer at Databricks, where he works on Postgres sync and realtime infrastructure for applications and AI agents. His work connects fast local interaction with shared, changing data. At Electric, that meant rebuilding an ambitious local-first platform around a smaller sync engine. After joining Neon at Databricks with the team in August 2026, it meant bringing realtime directly into a broader Postgres backend.

From open-source furniture to synthetic data

Before Electric, James co-founded Opendesk and served as its chief technology officer. He subsequently co-founded the synthetic-data company Hazy, also as CTO.

Hazy initially pursued an automated anonymization API. As the team encountered anonymization’s limitations, it shifted toward generating artificial datasets that retained statistical patterns and relationships from source data. Large enterprises’ data-access constraints also pushed the company toward on-premises software. James described the CTO’s responsibility as a bridge between commercial discovery and product development: understanding what customers would buy and why was part of deciding what to build.

Rebuilding Electric around a smaller core

At Electric, James worked alongside distributed-systems researchers, including co-founder Valter Balegas. He describes himself as a generalist developer and product builder, distinguishing his contribution from his collaborators’ underlying research. His practical concern was how applications could respond immediately to local actions while keeping shared data synchronized.

Electric’s initial ambition was a new distributed database. The difficulty of persuading customers to adopt another database pushed the team toward replication for existing systems, then toward syncing data into embedded client databases. That developed into an integrated platform for local-first applications, with migration tooling, authorization rules, generated clients and reactive data access.

The expanding platform became harder to develop and use. Early adopters encountered reliability and performance problems, while the team spent time fixing peripheral tooling. In the 2024 rebuild of Electric, James credited Kyle Mathews with helping sharpen a simpler approach: concentrate on the sync engine and let developers compose the surrounding stack.

Electric would replicate selected portions of Postgres data, called Shapes, over HTTP. Standard proxies and CDNs could help deliver and cache that data, while applications chose their own authorization and client libraries. The team initially limited the replacement to read-path sync rather than reproducing every write capability at once. That narrowed what Electric supplied, reducing the surrounding infrastructure developers had to adopt.

Another architectural change produced PGlite, the team’s embeddable Postgres project. Neon co-founder Nikita Shamgunov challenged Electric’s Postgres-to-SQLite approach because differences between the databases’ types would remain a source of trouble. He connected the team with Stas Kelvich’s experimental WebAssembly Postgres implementation. Electric developed that foundation into PGlite, making Postgres itself available inside browsers and other local environments. James and Valter recount that shared history with Neon as an important precursor to the teams coming together.

Shared state for people and agents

James’s later writing applies synchronization to agents’ messages, intermediate results and collaboration with people. He argues for architectures in which that work can persist beyond a single browser or execution environment.

• Durable Sessions. His Durable Sessions pattern makes an agent session persistent, addressable and available to multiple participants. A chat held only in one browser’s local state makes it difficult for colleagues to join midway, switch devices or review the work later. Shared, subscribable state lets people and agents participate in the same evolving session, retaining its history as they work.
• Serverless agents. In his serverless-agent architecture, James separates the agent’s decision loop, durable session data and tool execution. Stateless functions run agent logic, backend systems execute tools, and the data layer preserves progress. He objects to making an isolated computer the organizing unit for every managed agent because files and processes scattered across sandboxes complicate monitoring and collaboration. Tools that need sandboxes can still use them; the agent’s state and coordination need not live there too.

Bringing realtime into the backend

Joining Databricks changed Electric’s commercial direction as well as its engineering setting. In a September 2026 interview, James explained that he had come to see sync as a feature of a broader backend platform. Specialist infrastructure businesses faced a tighter market, while coding agents favored higher-level abstractions. Neon’s developer reach and Databricks’ enterprise distribution offered a faster route to making sync commonplace. Electric Cloud began winding down, while the team’s previously open-source projects remained open source.

In October 2026, James introduced Neon Realtime, built by the team inside Neon and Lakebase Postgres. Its live-query model keeps a query’s result current as underlying data changes. A sidebar showing channel names and unread-message counts, for example, can subscribe to the joined and aggregated result it displays. The application no longer has to interpret individual row-change notifications and decide what to refetch.

James also frames this architecture as a response to failures in agent-built applications. A separate realtime service introduces another permissions model and configuration, and can leave a preview application connected to production data. Neon Realtime is enabled per database branch and uses queries defined on the backend, where the application’s authentication already runs. The backend can seal a query so a subscribing browser or agent cannot alter it.

The implementation also preserves Neon's scale-to-zero behavior: clients connect to an ingress layer, so open subscriptions do not keep Postgres awake. Incremental query updates run on a replica. These choices address the tension James identifies between expressive queries and the cost of keeping their results live.

The October launch was a public beta, with material limits: row-level security was not yet supported, the protocol was still changing, and the team had not published benchmarks. James’s goal was to make realtime a default building block for developers and coding agents; the beta opened that work to broader use and testing.