In this special guest feature, Andrew Konoff, Technical Evangelist at Realm, discusses the benefits of mobilizing Postgres SQL databases for realtime applications. Andrew serves as Technical Evangelist at Realm, the leading third-party mobile database that powers high-performance, highly engaging end-user experiences for more than a billion users of mobile apps. The Realm Mobile Platform is ideal for building compelling user experiences through realtime collaboration, robust offline features, and live data synchronization.
There’s a lot to like about PostgreSQL. It’s free and open source, used and proven by millions of customers of all sizes, and after 15 years of development, it’s reliable, with new features in constant development. You can store JSON in a field now; you can have 30TB tables; you can change it as much as you want to fit your use case. It’s hard to not be a Postgres fan.
And yet, something’s wrong. The more you confront the real-time demands of web and mobile apps, the more you run into problems with scale and replication. NoSQL alternatives start to look very tempting — how else are you supposed to handle the fire hose of data that a collaboration-focused, real-time app throws at your servers?
Beyond sheer throughput, mobile apps face another huge problem: they go offline a lot. It may be because an elevator door closes or because you’ve driven outside of your carrier’s range, but sooner or later, no matter how well-maintained and scaled your Postgres database is, it will be as if it doesn’t exist.
When it comes to building a real-time friendly architecture for your apps, your options aren’t very tempting. You can spend development time and energy converting what’s in Postgres into something that works offline in a mobile app, but there are costs along the way. First, you’re serializing to JSON to get it to the app, then deserializing from an always-changing schema into objects that you can actually use locally. That introduces considerable fragility into the picture, and the never-ending serialization pipeline brings performance costs of its own, both on the server and the client.
Mobile has its own problems, but also its own developer-friendly solutions — ones that make real-time architectures a lot less painful to build. Backend developers would prefer not to completely migrate away from a stable backend, nor suddenly dump the scale of a new app onto a legacy system. Your app devs would like to avoid the fragility of converting the rows and tables of a SQL database into objects that they can use. And everyone would like to be able to ship an app with exciting real-time features like collaboration or chat, so that your end users get an experience they’ll enjoy.
One emerging alternative is the object database. It’s built off a simple premise: what if we could use true objects for persistence, rather than tables? That’d be great for mobile, given how dominant the object-oriented model is there. But while object databases had a brief moment of promise in the 1990s, they never really found their stride. Until now.
Object databases are easier for mobile devs from the get-go. You simply write your schema as a series of classes, and you create relationships and fields as properties on those classes. You’re working with the principles you know best, so you can move fast. You get a performance boost compared to working with SQLite and an ORM, because those objects get persisted as objects — there’s much less serialization and translation happening between the object-oriented world of mobile development and the declarative world of SQL.
So great. There’s a new piece of database technology. But that’s probably not at all reassuring if you’ve already got a working, useful Postgres installation, and are in the middle of contemplating how to build out a new mobile app. So why not have your cake and eat it too? With a Postgres-first architecture, an object database can have an important role as a bridge to mobile apps.
It’s simple. Make or keep Postgres as your database of record, set up Logical Decoding on your Postgres instance, and deploy a new object database-backed server that will be responsible for working with your new mobile app. Now, you’ve got a coherent log of changes happening on Postgres that your object server can subscribe to, add to your object database, and then — on committing your own transactions from your object database — write back into Postgres. And from the object server, those objects sync to any connected mobile devices, giving your mobile developers a way to fluently work with new data in an on-device, synchronized object database.
With this Postgres-first architecture, it means that you can use all the data you’ve got, but more easily build apps that people love. You don’t have to abandon your existing backend and Postgres deployments, and you don’t have to give up on realtime features or a robust offline-mode experiences that would normally be incredibly hard to build with a traditional Postgres-backed server.
Building new tech doesn’t mean throwing out all you have. It just means being pragmatic. And to deliver the really compelling app experiences that people have come to expect, pragmatism is warranted. By mobilizing your existing data platform, you get more people using your products in more places.
Sign up for the free insideAI News newsletter.
Speak Your Mind