![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Enabling real-time data synchronization has long been a notoriously expensive and challenging endeavor. But as the AI gold rush unfolds, real-time sync is no longer a nice-to-have but an imperative for AI applications to support resilient streaming, real-time collaboration, and fast, seamless user experiences.
Now, Electric SQL says they’re making it happen with their Postgres sync engine that solves the problems of partial replication, fan-out, and data delivery.
As described by one of the startup’s co-founders and CEO, James Arthur, Electric SQL offers “a different way of doing data transfer or data fetching for building software applications” — what he calls one of the fundamental concerns of software development: “It influences your developer experience, how much coding across the network you do, what your user experience is.”
With Electric SQL, the startup aims to solve the core problem of sync engines, giving developers a data infrastructure layer that can integrate into nearly any software, consume replication from a Postgres database, and then filter out the data to local applications. It’s also fully open source, with a community of 2,500+ open source developers in the project’s Discord channel.
But the path to solving real-time sync wasn’t a straight one.
Today, Electric SQL may define themselves as a state transfer technology — but that’s not how the project started out.
At the beginning, Arthur says the team was focused on building a next-generation geo-distributed database, using their technology and algorithms as a replication layer for existing databases, like Postgres, SQLite, etc.: “Then we saw, digging into use cases, this pattern of local-first software development, where people are building applications where you sync data into the local app, whether that’s the browser or a mobile app.”
It was at that point, according to Arthur, that the team realized what they were working on was actually ideally suited to solve the persistent problems of sync.
And so they ran with it.
A breakthrough in real-time sync has been a long time coming.
Expensive, time-consuming, and resource-intensive, building sync engines has traditionally been financially infeasible and thus out of reach for all but a few deep-pocketed companies. “It’s one of the most famously hard challenges in software development,” explains Arthur. “It takes literally millions of dollars worth of engineering time. You need senior engineers who know what they’re doing around distributed systems, database systems.”
Of course, money wasn’t the only obstacle keeping real-time sync from seeing the light.
Message delivery, for instance, was one sticky challenge. Consider: With a main database in the cloud and a smaller replica in a web browser or mobile application, keeping the two in sync is a bear of a task. “And you’re doing that over the last-mile public Internet onto user devices,” Arthur adds. “It’s famously extremely difficult.”
Real-time notifications added further trouble—and another reason to avoid real-time sync altogether and favor simpler stateless systems, like REST APIs or GraphQL.
Amidst these challenges, the industry also lacked a systemic library or framework solution. “Companies like Figma and Linear, they invested literally millions of dollars doing it because they wanted to be able to differentiate their products with the quality of their collaborative user experience,” notes Arthur. “But it’s not feasible for most software systems to put that much engineering into an infrastructure layer.”
With both engineering complexities and financial obstacles stifling innovation, the majority of sync engines that ended up being built only served specific domains. Generalizing a sync engine that the greater industry could use remained a seemingly far-off goal.
What finally changed? Arthur and ElectricSQL’s second co-founder and CTO, Valter Balegas, chalk it up to two big steps forward.
One, recent research advancements have dramatically pushed what is possible in the realm of distributed data systems, including, for example, the advent of CRDT (conflict-free replicated data type). More broadly, Arthur says, “there has been a step change in the understanding of how to do sync properly…and productize those capabilities into properly usable software.”
Beyond specific research gains, the steady march of technological progress has opened up new possibilities that make real-time sync viable. “If you go back 10 years ago, the compute resources and the capabilities of something like a web browser or somebody’s mobile phone were really quite low,” Arthur explained.
With limited storage and compute power, Arthur says it simply didn’t make sense to sync large amounts of data or run compute logic on consumer devices. But today’s high-speed, high-spec consumer devices—coupled with the significant developments in the research base—have unlocked the ability to take real-time sync generally.
In fact, real-time sync isn’t just finally technologically and financially doable — it’s necessary.
When the ElectricSQL team started building, real-time collaborative systems were dominating the scene. Now, AI applications are the hot ticket — and Arthur said ElectricSQL is the perfect way to keep the state in sync between AI workflows in the cloud and users working on local devices.
“AI apps are inherently multi-user. If you have a user talking to an AI agent and the AI agent is doing something, it’s going to be updating the state underneath that,” he explains. “You have to keep the user in the loop of what the agents are doing.”
Take a system like ChatGPT or Claude, for example. Right now, if the network connection drops, so does the stream. For the user, that means if you refresh the page, your data is gone. “Whereas with a system like ElectricSQL, you have resilient token streaming,” Arthur points out. “So you can always just resume the stream. You can have multiple users in the same session, and you can sync it out to multiple devices, multiple tabs.”
As AI systems become more sophisticated and start to replace previous generation software, Arthur stresses that this kind of resumability and multi-user, team-based functionalities will be crucial.
But while ElectricSQL says they’re so far seeing a lot of repeatability and many customers coming to them to build applications, Balegas admits it might take some time for the industry to get fully on board with real-time sync: “Real-time sync has often been seen as a bit of a complex other world to your normal application stack. And that’s one of the things we set out to try to change with ElectricSQL.”
Though Balegas acknowledges that ElectricSQL introduces a new paradigm in software development, he affirms that it’s now the best way of building applications — and it’s time for the industry to let go of its old habits.